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ABSTRACT 


This  thesis  outlines  the  development,  programming,  and  testing  a  logical  interface 
between  a  radar  system,  the  AN/SPS-65(V)1,  and  a  general- puipose  reconfigurable  com¬ 
puting  platform,  the  SRC  Computer,  Inc.  model,  the  SRC-6E.  To  confirm  the  proper  op¬ 
eration  of  the  interface  and  associated  subcomponents,  software  was  developed  to  per¬ 
form  basic  radar  signal  processing.  The  interface,  as  proven  by  the  signal  processing  re¬ 
sults,  accurately  reflects  radar  imagery  generated  by  the  radar  system  when  compared  to 
maps  of  the  surrounding  area.  The  research  accomplished  here  will  allow  follow-on  re¬ 
search  to  evaluate  the  potential  benefits  reconfigurable  computing  platforms  offer  for  ra¬ 
dar  signal  processing. 
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EXECUTIVE  SUMMARY 


This  thesis  is  a  part  of  a  larger  project,  which  is  to  compare  radar  signal  process¬ 
ing  on  a  general-purpose  computer  with  processing  on  more  traditional  radar  systems.  If 
the  processing  speed  is  significantly  greater  on  a  reconfigurable  computing  system,  this 
could  have  significant  military  implications.  Namely,  it  might  be  possible  to  replace  sev¬ 
eral,  purpose-built  radar  processing  systems  with  one  general-purpose  radar  processing 
system  thereby  saving  in  space  and  weight  on  military  platforms. 

The  reconfigurable  computer  used  contains  field  programmable  gate  arrays 
(FPGA),  or  Programmable  Logic  Device,  embedded  in  the  system  architecture.  FPGAs 
are  devices  which  can  be  programmed  to  implement  a  wide  variety  of  logic  circuits. 
FPGAs  exhibit  the  benefits  of  customized  hardware  processing  speeds  coupled  with  the 
ability  to  be  reconfigured  for  other  applications  in  a  maimer  similar  to  loading  a  new  pro¬ 
gram.  Given  this  speed  and  flexibility,  general-purpose  reconfigurable  computers  many 
standard  general-purpose  computer  systems  with  FPGAs.  The  intent  of  these  systems  is 
to  harness  the  benefits  of  FPGAs  in  standard  computing  platforms.  FPGAs  have  been 
shown  to  provide  significant  performance  speedups  in  signal  processing  tasks  over  tradi¬ 
tional  methods  [1]. 

With  the  potential  benefits  of  the  FPGA- based  processing  in  mind,  the  overall 
project  goal  was  to: 

1 .  Develop,  build,  and  test  a  physical  interface  required  to  pass  data  from  a  radar  sys¬ 

tem  to  a  general-purpose  reconfigurable  computing  device. 

2.  Develop,  configure,  and  test  the  logical  implementation  required  on  the  recon¬ 

figurable  computing  device  to  connect  to  the  interface.  This  step  also  includes 

sampling  and  storing  the  data  transferred  across  the  interface. 

3.  Process  the  radar  signal  data  for  display  and  compare  processing  speeds  to  tradi¬ 

tional  methods. 

This  thesis  developed  software  to  provide  a  reconfigurable  computing  system 
with  data  from  a  radar  system.  Also,  limited  radar  signal  processing  on  that  data  to 
proved  the  proper  operation  of  the  interface.  The  thesis  work  culminated  in  a  successful 

xvii 


test  of  the  processed  radar  image  of  the  Monterey  Bay  area.  When  compared  to  carto¬ 
graphic  information  of  Monterey  Bay,  the  processed  signal  strongly  correlated  to  map 
data. 

In  addition  to  the  successful  testing  of  the  logical  interface,  this  thesis  explored  a 
number  of  processing  methodologies  and  coding  complexities  encountered  with  the  re- 
configurable  computing  platform.  The  se  lessons  learned  and  the  suggested  future  work 
should  help  streamline  future  work  within  this  project. 


I.  INTRODUCTION 


A.  PROJECT  OBJECTIVE 

This  thesis  is  a  part  of  a  larger  project,  which  is  to  compare  radar  signal  process¬ 
ing  on  a  general-purpose  computer  with  processing  on  more  traditional  radar  systems.  If 
the  processing  speed  is  significantly  greater  on  a  reconfigurable  computing  system,  this 
could  have  significant  military  implications.  Namely,  it  might  be  possible  to  replace  sev¬ 
eral,  purpose-built  radar  processing  systems  with  one  general-purpose  radar  processing 
system  thereby  saving  in  space  and  weight  on  military  platforms. 

The  reconfigurable  computer  used  contains  field  programmable  gate  arrays 
(FPGA),  or  Programmable  Logic  Device,  embedded  in  the  system  architecture.  FPGAs 
are  hardware- based  devices  which  can  be  programmed  to  implement  a  wide  variety  of 
logic  circuits.  FPGAs  exhibit  the  benefits  of  customized  hardware  processing  speeds 
coupled  with  the  ability  to  be  reconfigured  for  other  applications  in  a  maimer  similar  to 
loading  a  new  program.  Given  this  speed  and  flexibility,  general-purpose  reconfigurable 
computers  marry  standard  general-purpose  computer  systems  with  FPGAs.  The  intent  is 
to  harness  the  FPGAs  benefits  in  standard  computing  platforms.  FPGAs  have  been 
shown  to  provide  significant  performance  speedups  in  signal  processing  tasks  over  tradi¬ 
tional  methods  [1 1. 

With  the  potential  benefits  of  the  FPGA  based  processing  in  mind,  the  overall 
project  goals  were  to: 

1.  Develop,  build,  and  test  a  physical  interface  required  to  pass  data  from  a  radar  sys¬ 
tem  to  a  general- puipose  reconfigurable  computing  device. 

2.  Develop,  configure,  and  test  the  logical  implementation  required  on  the  recon¬ 
figurable  computing  device  to  connect  to  the  interface.  This  step  also  includes 
sampling  and  storing  the  data  transferred  across  the  interface. 

3.  Process  the  radar  signal  data  for  display  and  compare  processing  speeds  to  tradi¬ 
tional  methods. 
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B.  THESIS  OBJECTIVE 

The  objective  of  this  thesis  was  to  develop,  implement  and  test  the  software  inter¬ 
face  between  a  radar  system  and  a  reconfigurable  computing  system.  To  test  the  inter¬ 
face  it  was  also  necessary  to  perform  limited  radar  signal  processing,  specifically  build¬ 
ing  a  range  map  from  returned  radar  signals.  The  objective  of  this  thesis  fulfills  the  over¬ 
all  project  goals  two  and  a  portion  of  goal  three.  Project  goal  one  was  accomplished  by 
the  Master’s  work  described  in  [2]. 

C.  THESIS  ORGANIZATION 

hi  order  to  accomplish  the  thesis  goals,  it  was  necessary  to  explore  the  radar  sys¬ 
tem,  the  AN/SPS-65(V)1,  and  the  interface  used  to  connect  to  the  reconfigurable  com¬ 
puting  platform.  This  is  described  in  Chapter  II.  Chapter  III  describes  the  hardware  and 
software  environment  of  the  reconfigurable  platform  used,  the  SRC-6E. 

Moving  from  the  physical  devices  used,  Chapter  IV  is  a  discussion  concerning 
logical  interface  designed  to  capture  data  presented  by  the  physical  interface  to  internal 
components  of  the  SRC-6E.  Within  the  SRC-6E  environment,  this  logical  connection  is 
called  a  macro. 

Chapters  V  and  VI  are  a  treatment  on  basic  radar  signal  generation  via  the 
AN/SPS-65(V)1  and  how  the  signal  can  be  processed  within  the  SRC-6E,  respectively. 
Given  this  base  of  knowledge,  software  to  perform  radar  range  image  processing  was 
written,  tested,  and  evaluated  as  detailed  in  Chapter  VII.  The  concluding  remarks.  Chap¬ 
ter  VIII,  highlights  objectives  accomplished  by  this  thesis,  some  of  the  limitations  of  the 
system  presented,  and  suggest  the  potential  direction  of  future  research 

The  general  flow  of  this  document  is  a  description  of  the  system  built  and  config¬ 
ured  stalling  with  the  radar  system  used,  the  physical  interface  built,  and  the  SRC-6E 
hardware  and  software  configuratioa  The  next  chapter  describes  the  general  characteris¬ 
tics  of  the  AN/SPS-65(V)1  and  the  analog- to-digital  (A/D)  converters  used  to  comiect 
the  SRC-6  E  to  the  AN/SPS-65(V)1. 
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n.  THE  AN/SPS-65(V)1  RADAR  SYSTEM  AND  AN  OVERVIEW 
OF  THE  A/D  CONVERTER  INTERFACE 

A.  INTRODUCTION 

As  mentioned  in  Chapter  I,  the  AN/SPS-65(V)1  was  used  as  the  radar  signal 
source.  This  chapter  explores  the  characteristics  of  the  AN/SPS-65(V)1  necessary  for 
understanding  subsequent  elements  of  this  thesis,  particularly  the  radar  signal  processing 
choices  made.  Also,  an  overview  of  the  A/D  converter  functionality  and  interface  signals 
provided  to  the  SRC-6E  are  outlined  in  this  chapter. 

B.  AN/SPS-65(V)1  RADAR  SYSTEM  FUNDAMENTALS 

1.  Radar  Purpose  and  Basic  Functionality 

The  AN/S  PS-65  (V)l  was  designed  to  provide  radar  detection  of  moving,  low  fly¬ 
ing  targets  via  Doppler  processing  [3],  Doppler  processing  requires  an  analysis  of  the 
phase  component  of  a  returned  radar  signal 

The  phase  shift  of  the  returned  signal  in  reference  to  the  transmitted  pulse,  can  be 
used  to  determine  the  speed  and  direction  of  a  target  [4].  The  time  which  the  signal  re¬ 
turns  with  respect  to  the  transmission  of  a  radar  pulse  is  used  to  determine  the  range  of 
the  target.  The  phase  and  distance  information  is  represented  by  two  signals  within  the 
AN/SPS-65(V)1  on  the  I  and  Q  channels.  Each  of  these  signals  is  imposed  on  a  30- MHz 
carrier  wave  [3],  Also,  a  reference  signal  allows  the  radar  system  to  resolve  the  approxi¬ 
mate  direction  of  the  target  in  reference  to  the  antenna  position. 

2.  Radar  Signals  Provided  to  the  A/D  Converters 

The  following  signals  were  provided  to  the  A/D  converters,  with  one  exception  as 
noted  below. 

a.  I  and  Q  Signals 

As  outlined  above,  the  I  and  Q  signals  provide  the  phase  shift  and  range 
information  of  a  target.  The  range  of  a  target  can  be  extracted  solely  from  the  informa¬ 
tion  presented  in  either  channel. 
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b.  Pulse  Repetition  Frequency  (PRF) 

The  transmission  of  a  pulse  through  the  antenna  occurs  at  a  specific  rate. 
This  rate  is  called  PRF  and  is  represented  as  an  electrical  signal  within  the  AN/SPS- 
65(V)1.  The  PRF  signal  triggers  the  process  by  which  the  transmission  radar  pulse  oc¬ 
curs.  The  PRF  trigger  signal  is  periodic  and  can  be  manually  or  automatically  adjusted 
during  operation  of  the  AN/SPS-65(V)1  [3],  In  this  analysis,  the  PRF  rate  was  3,064 
pulses  per  second. 

c.  Automatic  Gain  Control  (AGC) 

The  AGC  signal  indicates  the  relative  strength  of  the  received  signal.  The 
AGC  keeps  the  detected  signal  within  a  certain  amplitude  range  to  protect  the  receiving 
equipment.  The  relative  strength  of  amplification  or  attenuation  is  reported  to  the  radar 
signal  processor  via  the  AGC  signal.  This  signal  was  provided  to  the  A/D  converters  and 
to  the  SRC-6E.  The  AGC  signal,  however,  was  not  used  in  the  processing  of  the  radar 
signal  for  this  thesis,  as  the  signal  strength  remained  constant  at  all  times  during  experi¬ 
mentation. 

d.  Directional  Information 

The  AN/SPS-65(V)1  also  provides  a  reference  signal  which  is  used  to  de¬ 
termine  the  direction  of  the  antenna.  This  signal,  however,  was  not  used  in  the  design  of 
the  A/D  converter’s.  As  a  result,  there  is  no  automated  manner  to  determine  the  relative 
direction  of  the  antenna  at  any  given  time.  Given  the  objective  of  this  thesis,  this  was  not 
a  significant  issue,  but  did  limit  the  automated  radar  signal  processing  for  this  thesis  to 
essentially  range  information. 

C.  OVERVIEW  OF  THE  ANALOG- TO -DIGITAL  (A/D)  CONVERTERS 
FUNCTIONALITY 

As  mentioned  above,  the  A/D  converters  are  devices  designed  and  built  as  the  in¬ 
terface  between  the  AN/SPS-65(V)1  and  the  SRC-6E.  The  A/D  converters  provide  three 
basic  functions:  sample  the  voltage  levels  of  the  analog  signals  from  the  radar-;  convert 
the  analog  signals  to  digital;  and  present  digitally  encoded  radar  signals  to  the  SRC  gen¬ 
eral-purpose  I/O  port.  This  port  is  described  in  further  detail  in  Chapter  III.  The  follow¬ 
ing  material  is  an  over-view  of  the  A/D  converters  from  [2], 
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Operational  Speed  and  Effects 

The  A/D  converters  require  a  clock  source  to  effectively  sample  the  30- MHz  sig¬ 
nals  coming  from  the  radar  system.  This  is  within  the  capabilities  of  the  A/D  converters 
which  were  designed  to  operate  at  100  or  200  MHz. 

2.  Signal  Provided  to  the  A/D  Converters  from  the  SRC-6E 

The  A/D  converters,  however,  do  not  provide  an  internal  clock  source.  The  clock 
for  the  A/D  converters  is  sourced  from  the  SRC-6E  general-purpose  I/O  port  via  opera¬ 
tions  built  into  the  FPGAs.  These  operations,  or  macros,  can  route  and  multiply  the 
SRC-6E  clock  signal.  The  SRC-6E  has  an  internal  clock  which  operates  at  100  MHz. 
Through  multiplication,  the  clocking  signal  can  easily  double  to  200  MHz. 

3.  Signals  Provided  to  the  SRC-6E  from  the  A/D  Converters 

Depending  on  the  mode  of  operation,  the  A/D  converters  provided  the  following 

signals  to  the  SRC-6E:  I  primary,  I  secondary,  Q  primary,  Q  secondary,  Data  Ready, 

PRF  and  AGC. 

a.  I  and  Q  Primary  and  Secondary  Signals 

In  the  100- MHz  mode,  the  A/D  converters  sample  the  I  and  Q  channels 
and  provide  an  8-bit  signal  for  each  channel  at  a  sampling  rate  of  100  MHz.  These  8-bit 
signals  are  called  I  primary  and  Q  primary,  respectively.  When  sampling  at  200  MHz, 
the  A/D  converters  represent  each  channel  with  two  8-bit  signals.  While  the  I  and  Q 
channel  information  is  sent  to  the  SRC-6E  at  100  MHz,  the  effective  data  rate  is  200 
MHz.  The  four  signals  are  referred  to  as  I  primary,  I  secondary,  Q  primary,  and  Q  sec¬ 
ondary.  The  A/D  converters  sampled  the  radar  signals  at  100  MHz  for  testing  throughout 
this  thesis. 

b.  Data  Ready  Signal 

The  Data  Ready  signal  is  essentially  the  clock  used  by  the  A/D  converters. 
When  the  Data  Ready  signal  transitions  from  low-to-high  (voltage),  the  data  presented  on 
the  other  signals  is  valid.  This  signal  was  used  to  capture  valid  data  for  storage.  Data 
Ready  is  a  1-bit  signal  and  originates  from  the  A/D  converters. 
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c.  PRF 

The  PRF  signal  within  the  A/D  converters  is  a  level- shifted  version  of  the 
PRF  signal  from  the  AN/SPS-65(V)1.  The  AN/SPS-65(V)1  PRF  signal  was  level- 
shifted  and  fed  directly  in  the  SRC-6E  as  a  1-bit  signal. 

d.  AGC 

The  AGC  signal  is  the  sampled  version  of  the  AGC  signal  from  the  radar 
system.  As  with  the  I  and  Q  channels,  the  AGC  signal  from  the  A/D  converters  are  two 
8-bit  signals,  AGC  primary  and  AGC  secondary.  Both  the  primary  and  secondary  signals 
are  used  if  the  A/D  converters  are  sampling  at  200  MHz  and  only  the  primary  signal  at 
100  MHz. 

4.  Voltage  Representation  of  the  Radar  Signals 

The  relative  strength  of  the  radar  signal  return  is  captured  as  a  voltage  level  within 
the  AN/SPS-65(V)1.  Objects  which  reflect  a  greater  portion  of  the  radar  pulse  are  repre¬ 
sented  with  a  higher  voltage  level  on  the  I  and  Q  channels  of  the  radar  than  those  with  a 
lesser  reflectivity.  The  A/D  converters  represent  the  sampled  voltage  level  with  8-bits. 
This  provides  256  discrete  levels  which  represent  the  input  voltage  from  the  radar. 

The  most  negative  value  of  the  input  voltage  is  represented  by  0,  the  voltage 
maximum  by  256,  and  the  zero  voltage  level  by  128.  Given  a  5-volt  peak-to-peak  input 
sine  wave,  the  voltages  +2.5  v,  0  v,  and  -2.5  v  would  be  represented  by  255,  128,  and  0, 
respectively,  with  eight  bits.  This  format  for  representing  data  is  also  known  as  offset  bi¬ 
nary. 

Once  the  8-bit  representation  has  been  sampled  and  stored  in  the  SRC-6E,  it  must 
be  converted  again  to  reproduce  the  actual  voltage  presented  to  the  A/D  converters  by  the 
AN/SPS-65(V)1.  This  was  done  with  the  following  equation  where  the  signal  voltage  is: 

s[V]  =  a(fc-128).  (2.1) 

The  constant  a  is  a  simple  scaling  factor  used  to  reconstruct  the  actual  voltage 
level  at  the  tune  of  sampling  and  b  is  the  8- bit  value.  Using  Eq.  (2.1),  it  possible  to  rec¬ 
reate  both  the  positive  and  negative  voltage  levels  sampled  from  the  radar. 

The  voltage  conversion  equation  above  will  be  used  in  later  chapters  as  pail  of  the 

radar  signal  processing.  The  signals  presented  by  the  AN/SPS-65(V)1  to  the  A/D  con- 
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verters  are  also  used  in  the  processing  of  the  radar  signals  in  the  SRC-6E  general-purpose 
reconfigurable  computing  platform.  An  adequate  discussion  of  the  image  processing 
must  take  into  account  the  platform  on  which  the  processing  took  place.  An  exploration 
of  that  platform  is  the  subject  of  the  next  chapter. 
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m.  THE  SRC-6E  SYSTEM 


A.  INTRODUCTION 

In  this  project,  the  A/D  converters  and  the  radar  system  ultimately  connect  to  the 
SRC-6E.  The  sampling,  storing,  and  a  portion  of  the  processing  of  the  radar  signal  will 
be  done  within  the  SRC-6E.  The  means  by  which  the  processing  takes  place  is  the 
subject  of  following  chapters.  Those  discussions,  however,  must  be  based  on  an 
understanding  of  the  hardware,  software,  and  programming  environment  of  the  SRC-6E. 
That  is  the  subject  of  this  chapter. 


B.  SRC  HARDWARE  ENVIRONMENT 

As  mentioned  in  the  introduction,  the  SRC-6E  is  a  general- puipose 
reconfigurable  computing  platform.  The  SRC-6E  contains  two  Intel®  processing  systems 
and  one  Multi- Adaptive  Processing  (MAP®)  board  [5]  containing  four  FPGAs. 

1.  Microprocessor  Side  of  the  SRC-6E 

The  microprocessor  side  of  the  SRC-6E  is  composed  of  two  general-purpose 
personal  computers  (PC).  Each  PC  has  two  Intel  Pentium®  III  processors.  We  used  only 
one  of  the  general- puipose  computers.  As  with  most  PCs,  there  is  a  memory  bus 
connecting  various  components  within  the  system.  The  interconnect  between  the 
microprocessor  and  MAP  side  of  the  SRC-6E  is  done  via  a  SNAP1  M  card  interface  that 
connects  the  microprocesor  memory  bus  to  one  half  of  the  MAP  board  [6].  Memory 
transfer  between  the  microprocessor  side  and  the  MAP  side  can  be  accomplished  through 
standard  Direct  Memory  Access  (DMA)  methods  [5]  across  this  interconnect.  Memory 
space  on  the  microprocessor  is  Common  Memoiy,  as  programs  running  on  the 
microprocessor  or  the  MAP  can  access  it  [6], 

2.  MAP  Side  of  the  SRC-6E 

The  MAP  board  is  composed  of  two  MAP  processors.  Each  MAP  processor  is 
composed  of  two  FPGAs,  associated  memory,  and  the  required  control  circuitry  to  im¬ 
plement  the  functionality  of  the  MAP  processor. 
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a.  MAP  Connectivity 

As  described  above,  one  of  MAP  processors  (MAPO)  is  connected  to  a 
microprocessor  via  a  SNAP  interconnect.  The  second  MAP  processor  (MAPI)  is  con¬ 
nected  to  the  second  microprocessor  system  [7],  Individual  MAP  processors,  MAPO  and 
MAPI  in  this  example,  each  have  an  input  and  an  output  chain  port.  A  chain  port  is  a 
connection  used  to  connect  two  or  more  MAPs  together  in  a  daisy  chain.  Through  user- 
developed  macros,  a  chain  port  can  be  converted  into  a  general- puipose  I/O  port  [8], 


Figure  1.  Internal  components  of  the  SRC-6E. 

While  a  chain  port  and  a  general- puipose  I/O  port  are  physically  the  same 
device,  they  are  functionally  different.  The  general- puipose  I/O  port  function  is  used  to 
comiect  a  MAP  system  to  some  external  device.  Chain  ports  connect  MAPs  to  other 
MAPs.  The  port  which  the  A/D  converters  connect  to  the  SRC-6E  is  a  general- puipose 
I/O  port. 


10 


Each  general-purpose  I/O  port  has  a  collection  of  I/O  pads.  This  is  where 
physical  contact  between  the  A/D  converters  and  the  SRC-6E  takes  place.  The  specfic 
connection  names  between  these  to  systems  is  outlined  in  Appendix  B. 

b.  MAP  Memory 

MAP  functions  (program  fragments  running  on  the  MAP)  can  access  the 
memory  resident  on  the  MAP.  One  component  on  a  MAP  is  the  On  Board  Memory 
(OBM)  as  shown  in  Fig.  1 .  There  is  a  total  of  24  MB  of  memory  on  an  individual  MAP. 
The  24  MB  is  divided  evenly  between  six  banks,  each  of  4  MB.  A  single  bank  of  OBM 
is  conceptually  organized  as  a  two-dimensional  array  where  each  element  is  64  bits  wide. 
The  maximum  number  of  elements  in  a  single  OBM  bank  is  523,776.  The  organization 
of  OBM  memory  allows  for  the  access  of  multiple  (six)  memory  locations  on  each  clock 
cycle.  This  aspect  of  memory  access  within  the  MAP  facilitates  parallel  processes.  [5, 

6]. 

C.  SRC-6E  SOFTWARE  ENVIRONMENT 

The  SRC-6E  software  components  were  designed  to  abstract  the  details  of  the 
hardware  system  itself  from  the  general  programmer.  When  writing  programs  designed 
to  take  advantage  of  the  FPGAs,  a  programmer  can  code  in  either  FORTRAN  or  C  [6], 
The  main  program  should  call  on  functions  which  have  been  ported  over  to  the  MAP  to 
take  advantage  of  the  potential  speed-up  an  FPGA  offers.  It  is  up  to  the  individual  pro¬ 
grammer  to  determine  which  aspect  of  a  program  would  benefit,  in  teims  of  speed,  by 
running  on  an  FPGA.  The  C  language  was  used  on  the  microprocessor  and  MAP  side 
functions  of  the  SRC-6E  throughout  this  thesis. 

A  program  that  is  executed  on  the  MAP  side  is  written  as  a  C  function  and  is 
called  a  MAP  function.  The  main  program,  running  on  the  microprocessor  side,  calls  and 
passes  data  in  a  manner  similar  to  that  of  regular  function  calls  in  C. 

MAP  functions,  while  written  in  C,  are  converted  to  a  Hardware  Description 
Fanguage  (HDF)  by  the  SRC-6E  compiler.  Compiling  C  to  HDF  is  accomplished 
through  a  series  of  SRC-6E  defined  macros.  These  system- defined  macros  are  segments 
of  code  that  provide  the  abstraction  from  system  hardware  that  programmers  have  come 
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to  expect  in  modem  systems.  Programmers  can,  however,  extend  the  range  of 
functionality  provided  by  system- defined  macros  by  creating  user-defined  macros.  These 
user- defined  macros  must  be  written  in  an  HDL,  such  as  VERILOG  or  VHDL.  While 
MAP  functions  cannot  call  upon  other  functions,  they  can  explicitly  call  on  user- defined 
macros. 

The  user-defined  macros  developed  in  Chapter  IV  were  ‘written’  orginally  as 
circuit  diagrams.  These  circuit  diagrams  were  automatically  converted  into  VHDL  and 
then  ported  into  the  SRC-6E  programming  environment. 

This  chapter,  in  summary,  outlined  the  basic  hardware  and  software  components 
of  the  SRC-6E.  Memory,  DMA,  microprocessor  side,  MAP  side,  MAP  functions,  and 
macros  are  all  concepts  upon  which  this  thesis  is  built.  It  is  now  possible  to  begin  the 
discussion  of  the  various  elements  developed  to  accomplish  the  thesis  objectives.  The 
next  chapter  is  a  discussion  of  the  macros  developed  to  interface  the  logical  components 
of  the  SRC-6E  and  A/D  converters. 
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IV.  BUILDING  A  MACRO  IN  THE  SRC-6E  ENVIRONMENT 


A.  INTRODUCTION 

As  mentioned  in  Chapter  III,  a  macro  within  the  SRC-6E  is  a  section  of  code 
written  in  a  HDL  that  allows  the  programmer  to  define  special  tasks  for  MAP  functions 
to  call  upon  MAP  functions  cannot  call  other  functions  as  is  possible  in  a  C  program¬ 
ming  environment.  MAP  functions  call  on  a  collection  of  system- defined  and/or  user- 
defined  macros  to  accomplish  special-purpose  tasks. 

User-defined  macros  allow  the  programmer  to  extend  the  range  of  applications  for 
MAP  functions  from  what  is  provided  by  the  system- defined  macros.  Programming  a 
user- defined  macro  requires  knowledge  of  digital  logic  design,  an  HDL  language  (or 
symbology),  and  possibly  a  set  of  tools  to  allow  for  the  generation  of  HDL  code  from  a 
macro  schematic. 

This  chapter  outlines  the  process  taken  to  create  a  series  of  macros  that,  in  turn, 
allowed  for  the  collection  of  radar  signals  for  processing  in  the  SRC-6E.  To  further  ex¬ 
plain  the  macros  created  in  this  thesis,  a  discussion  of  the  different  types  of  macros  and 
how  a  macro  is  interfaced  in  the  SRC-6E  is  required. 


B.  MACROS  TYPES  AND  INTERFACING  PROGRAMS  AND 

PROGRAMABLE  COMPONENTS  IN  THE  SRC-6 E 

Within  the  SRC-6E  MAP  programming  environment,  there  are  five  types  of  mac¬ 
ros  [6].  Of  these  five,  two  were  used  in  this  thesis,  the  purely  functional  macro  and  ex¬ 
ternal  macro. 

1.  Purely  Functional  Macros 

Purely  functional  macros  are  called  and  then  return  a  value  or  values  to  the  calhng 
MAP  function.  Such  macros  do  not  have  any  state  values.  These  macros  can  be  pipe¬ 
lined  such  that  they  can  accept  new  input  data  while  internally  processing  the  results  from 
previous  input  values  [6]. 

Since  the  radar  processing  interface  works  at  the  internal  clock  speed  of  the  SRC- 
6E  MAP,  100  MHz,  it  is  important  that  any  macro  developed  operate  at  that  clock  speed. 


13 


A  significant  feature  of  purely  functional  macros  is  that  they  can  be  pipelined  and  exe¬ 
cuted  in  parallel  to  maximize  clocking  efficiency  with  respect  to  data  input. 

2.  External  Macros 

External  macros  interact  with  parts  of  the  system  beyond  the  code  block  in  which 
it  operates  [6].  It  was  initially  thought  that  these  types  of  macros  would  be  required  to  in¬ 
terface  with  the  A/D  converters  to  retrieve  data  presented  on  the  general-purpose  I/O 
port.  This  turned  out  to  be  incorrect.  It  was,  however,  not  discovered  until  later  in  the 
macro  development  cycle  and  is  covered  in  more  detail  later  in  this  chapter. 

External  macros  require  an  implicit  stall  and  done  signal  added  to  the  macro  code 
as  well  as  the  black  box  file  (see  Section  3. a).  The  stall  and  done  signals  are  system  con¬ 
trol  signals  that  facilitate  the  passing  of  system  control  to  and  from  an  external  macro. 

The  start  signal  is  initiated  by  the  SRC  to  the  external  macro  indicating  that  the  external 
macro  should  begin  execution.  The  done  signal  originates  in  the  macro  and  indicates  to 
the  SRC  that  it  has  completed  execution 

3.  Macro -to- MAP  Function  Interface 

In  order  to  facilitate  compilation  of  MAP  function  calls  of  macro  code,  two  user- 
defined  files  characterize  the  nature  of  the  interface.  These  files  are  called  ‘black  box’ 
and  ‘info’  within  SRC  documentation  [6], 
a.  Black  Box  Files 

Black  box  files  are  a  description  of  the  macro  inputs  and  outputs  from  the 
perspective  of  the  MAP  function  and  SRC-6E  system-defined  signals.  An  example  of  a 
SRC  defined  signal  would  be  the  clock  signal,  labeled  CLK  in  Fig.  2.  No  other  function¬ 
ality  of  the  macro  is  revealed  in  the  black  box  file.  Figure  2  contains  a  typical  black  box 
schematic  of  a  macro,  while  Fig.  3  contains  the  actual  coding  used  to  represent  it. 


IFD 


Figure  2.  Black  box  diagram  of  a  macro. 
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module  bitin  (CLK,  INI) ; 
input  CLK; 
output  INI; 

endmodule _ 

Figure  3.  Black  box  file  written  in  Verilog  HDL. 

Notice  that  the  K9  input  signal  shown  in  Fig.  2  is  not  included  in  the  black 
box  file  in  Fig.  3.  As  mentioned  above,  a  black  box  file  is  written  from  the  perspective  of 
a  MAP  function  and  system- defined  signals.  In  Fig.  2,  the  signal  INI  is  returned  to  the 
calling  MAP  function.  For  this  example,  assume  the  input  K9  is  not  a  standard  system 
signal,  like  CLK,  and  is  not  provided  by  a  MAP  function  to  the  macro.  As  such,  the  sig¬ 
nal  K9  is  not  written  into  code  in  Fig.  3. 

If  the  K9  input  was  included  in  the  black  box  file,  the  SRC-6E  compiler 
would  attempt  to  connect  the  input  to  essentially  a  random  MAP  function  variable 
defined  in  the  black  box  file.  This  system-  induced  connection  then  causes  ambiguity  in 
the  circuit  connections  and  a  resulting  compiler  error. 

This  SRC -induced  nuance  is  counterintuitive  when  thinking  of  black  box 
descriptions  in  general.  Discovering  this  nuance  took  several  weeks  of  research  and  it  is 
mentioned  here  in  hopes  that  follow-on  research  will  benefit  from  this  discussion. 

b.  Info  Files 

Info  files  establish  the  mapping  of  operators  and  calls  in  the  MAP  function 
to  the  macro  signal  names  [6],  The  info  file  defines  the  name  of  the  macro  to  be  called, 
the  type  of  macro  (pure  functional,  external,  or  one  of  the  other  three  types),  the  macro 
latency,  and  other  characteristics  of  the  macro. 

Figure  4  is  the  info  file  code  required  for  the  macro  diagram  shown  in  Fig. 
2.  It  defines  the  macro  as  not  stateful  and  not  external.  As  a  result,  the  macro  type  de¬ 
faults  to  functional.  The  info  file  characterizes  the  macro  as  taking  one  clock  cycle  to 
execute  (latency).  Further,  the  macro  can  be  pipelined.  There  are  no  inputs  and  there  is 
one  output  which  is  one  bit  wide.  The  macro  also  uses  the  standard  SRC-6E  system  sig¬ 
nal  ‘clock.’  Once  again,  the  input  K9  was  not  defined  in  the  info  file  for  the  same  rea¬ 
sons  that  it  was  not  defined  in  the  black  box  file. 
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BEGIN_DEF  "bitin" 

MACRO  =  "bitin"; 
STATEFUL  =  NO; 
EXTERNAL  =  NO; 
PIPELINED  =  YES; 
LATENCY  =  1; 

INPUTS  =  0 : 


OUTPUTS  =  1: 

OO  =  INT  1  BITS  (INI) 


IN_SIGNAL:  1  BITS  "CLK"  =  "CLOCK"; 
END  DEF 


Figure  4.  Sample  info  file. 

C.  MARCO  DEVELOPMENT  FOR  RADAR  IMAGE  RETRIEVAL 

Initially,  a  macro  was  to  be  written  to  provide: 

•  16  bits  of  I  channel  data  to  the  MAP  function  from  the  A/D  converters. 

•  16  bits  of  Q  channel  data  to  the  MAP  function  from  the  A/D  converters. 

•  16  bits  of  AGC  data  to  the  MAP  function  from  the  A/D  converters. 

•  1  bit  of  PRF  data  to  the  MAP  function  from  the  A/D  converters. 

•  A  Data  Ready  signal  to  the  components  within  the  macro  from  the  A/D 
converters. 

•  A  doubled  SRC-6E  system  clock  signal  from  the  macro  to  the  A/D  con¬ 
verters.  For  various  reasons,  this  was  later  changed  to  100  MHz  while 
maintaining  the  capability  to  double  the  clock  speed. 

•  Synchronization  of  the  clock  domains  between  the  SRC-6E  and  the  A/D 
converters  in  order  to  minimize  clock  skewing  problems. 

Macro  development  that  would  accomplish  the  above  points  was  decomposed  into 

two  subcategories,  writing  data  out  of  and  reading  data  into  the  SRC-6E  system  across  a 

general-purpose  I/O  port. 

All  macros  were  drawn  as  schematics  and  then  automatically  translated  by  the 
Xilinx®  application  Project  Navigator,  release  version  6.2.03i,  into  VHDL  code.  The  re¬ 
sultant  code  was  then  imported  as  a  macro  file  into  the  SRC-6E  programming  environ¬ 
ment.  For  the  purposes  of  this  thesis,  macros  will  be  represented  by  schematics  for  sim- 
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plicity.  As  the  schematics  are  logic  circuits,  the  term  circuit  will  be  used  synonymously 
with  the  term  macro.  Pad  names  follow  the  conventions  set  forth  in  the  connectivity  dia¬ 
grams  in  Appendix  B. 

1.  Data/Clock  Out  of  the  SRC-6E 

Figure  5  is  the  schematic  that  was  used  to  generate  the  clock  signal  out  of  the 
SRC-6E  at  100  MHz  via  a  Digital  Clock  Manager  (DCM).  It  was  initially  thought  that, 
since  this  macro  would  interface  with  elements  outside  of  the  code  block,  the  macro  must 
be  defined  as  external.  This  turned  out  later  to  not  be  the  case  and  subsequent  versions  of 
the  clock  output  macro  were  defined  as  purely  functional. 

hi  Fig.  5,  the  clock  output  cannot  be  fed  directly  to  a  Xilinx  pad  but  must  first  be 
buffered  by  an  output  buffer.  For  this  experiment,  an  OBUF_F_24  was  used  which  pro¬ 
vides  a  fast  slew  rate  and  drive  power  of  24  mA  for  a  low  voltage  transistor- transistor 
logic  (LVTTL)  pad  [9],  The  BUFG,  Global  Clock  Buffer  [9],  provides  a  tap  point  for  the 
clock  feedback  line.  The  clock  feedback  circuitry  synchronized  the  clock  output  of  the 
DCM  (CLKO)  to  the  clock  input  into  the  DCM  (CLK).  The  START/DONE  elements  of 
the  circuit  served  to  fulfill  the  SRC-6 E  requirements  for  external  macros. 
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Figure  5.  Initial  clock  output  macro /circuit. 
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Using  this  macro  and  a  digital  oscilloscope,  the  voltage  output  from  the  SRC-6E 
was  recorded  as  shown  in  Fig.  6.  The  clock  provided  by  the  SRC-6E  is  a  100- MHz 
square  wave,  but  due  to  imperfect  impedance  matching  and  the  poor  frequency  response 
of  the  observing  equipment,  the  clock  signal  appears  sinusoidal. 


Tek  Run:  2.00GS/S  Sample 

[ - -T- - ] 


Figure  6.  100-MHz  clock  output  using  externally  defined  macro. 

With  subsequent  experiments,  the  clock  speed  could  be  manipulated  to  nearly  any 
desired  value  when  using  flip  flops  or  counters.  The  DCM,  provided  by  Xilinx,  has  a 
feature  called  synthetic  frequency  division  which  is  supposed  to  divide  the  frequency  of 
the  signal.  It  was  found,  however,  that  synthetic  frequency  division  via  the  DCM  did  not 
work.  SRC  documentation  supported  this  finding  [10].  Whether  this  is  an  artifact  of  the 
Xilinx  implementation  of  a  DCM,  an  SRC  implementation  of  a  Xilinx  FPGA,  or  a  com¬ 
bination  of  the  two  is  unknown  to  this  author. 

2.  One -Bit  Data  Input  Into  the  MAP  of  the  SRC-6E 

After  establishing  an  output  clock,  reading  data  as  variables  into  the  SRC-6E  re¬ 
mained.  While  the  eventual  goal  was  to  read  upwards  of  25-50  data  pins,  initial  efforts 
focused  on  simply  reading  one  bit  at  a  clock  rate  of  100  MHz  and  storing  that  data  for 
analysis. 

A  purely  functional  macro  schematic  was  created  as  shown  in  Fig.  7.  The  macro 
stores  the  logic  value  from  the  pad  into  an  I/O  D-flip  flop  on  every  positive  edge  from  the 
SRC-6E  system  clock.  Once  stored,  the  data  is  presented  on  the  output  labeled  INI. 
Through  the  interfaces  defined  in  the  info  and  black  box  files,  INI  was  read  in  as  a  32- bit 
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integer  variable,  sign  extended  as  a  64-bit  integer,  and  stored  as  a  64-bit  element  in  an 
OBM  bank  on  the  MAP.  Once  several  thousand  samples  were  collected,  the  OBM  bank 
contents  were  transferred  via  a  DMA  transaction  to  the  microprocessor  side  and  either 
displayed  on  screen  or  stored  as  a  file  for  later  analysis. 


mn> 


Figure  7.  One -bit  input  macro. 


The  input  pad,  T12,  was  connected  to  a  function  generator  during  the  tests.  The 
function  generator  created  a  square  wave  signal  operating  at  1  kHz  between  at  the  ranges 
of  logic  values  1  and  0  for  LVTTL  circuitry  with  at  50%  duty  cycle.  For  a  given  cycle  in 
the  square  wave  at  1  kHz  and  a  sampling  rate  of  100  MHz,  there  were  approximately  50 
logic  Is  and  50  logic  0s  in  the  output  file.  This  indicated  that  the  input  signal  was  sam¬ 
pled  and  stored  at  a  rate  of  100  MHz. 

3.  Multiple  Bit  Input  into  the  SRC-6E 

Working  from  the  techniques  defined  in  the  one-bit  input  example,  a  two-bit-  in¬ 
parallel  input  macro  was  created  but  proved  not  to  function  properly.  As  mentioned  ear¬ 
lier,  the  one-bit  input  signal  was  implicitly  read  as  a  32- bit  integer  before  being  sign  ex¬ 
tended  into  a  64-bit  element  in  an  array.  The  ‘expansion’  of  the  one-bit  signal  to  a  64-bit 
variable  was  done  implicitly  by  the  SRC  compiler  with  system- defined  macros.  This  im¬ 
plicit  process  did  not  seem  to  be  supported  by  the  compiler  for  signal  values  two  or  four 
bits  wide.  Signal  values  of  eight,  16,  and  32  bits  were  properly  converted  to  64-bit  vari¬ 
ables  by  the  compiler. 

Eventually,  an  encompassing  macro  was  developed  to  read  two  8-bit  I  channel 
words,  two  8-bit  Q  channel  words,  a  one-bit  PRF  signal,  and  a  one-bit  Data  Ready  signal. 
The  I  and  Q  channel  bits  were  defined  as  a  single  32-bit  integer  variable.  The  least  sig¬ 
nificant  16-bits  represented  the  I  channel  information  while  the  remaining  bits  represent 
the  Q  channel  information  as  shown  in  Table  1  below. 
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Table  1.  Data  division  of  input  signals. 


Q  Channel 

I  Channel 

Bits  represent 

Q  secondary 

Q  primary 

I  Secondary 

I  primary 

Bit  positions 

31:24 

23:16 

15:8 

7:0 

This  purely  functional  macro  was  tested  and  operated  as  expected. 

4.  Combining  Clock  Output  with  Data  Input  in  a  Macro 

The  next  step  in  the  macro  development  process  was  to  combine  the  externally 
defined  clock  output  macro  with  the  purely  functional  data  input  macro.  The  resultant 
circuit  would  effectively  become  an  externally  defined  macro.  Upon  testing  this  circuit, 
however,  the  sampling- and- storage  rate  dropped  to  approximately  10  MHz. 

Externally  defined  macros  actually  operate  in  a  code  block  that  is  separate  from 
the  MAP  function.  When  the  MAP  function  called  the  external  macro,  control  of  the  sys¬ 
tem  was  passed  to  the  macro.  When  the  macro  finished,  control  was  passed  back  to  the 
MAP  function.  This  passing  of  system  control  incurred  a  severe  performance  penalty  of 
90%.  The  external  definition  was  removed  and  the  sampling- and- storage  rate  returned  to 
100  MHz. 

The  macro  finally  developed  to  read  and  write  data  from  the  A/D  converters  inter¬ 
face  to  the  SRC-6E  is  fully  described  pictorially  and  in  VHDL  in  Appendix  C. 


D.  TESTING  THE  RADAR  INTERFACE  MACRO 

While  testing  of  the  macros  continued  throughout  the  design  process,  only  the  fi¬ 
nal  design  testing  process  is  discussed  here. 

1.  Test  Equipment  Setup 

The  I  channel  primary  connection  from  the  A/D  converters  were  connected  to  the 
SRC-6E  per  the  tables  in  Appendix  B.  Instead  of  the  AN/SPS-65(V)1  connected  to  the 
A/D  converter  interface,  a  signal  generator  emitting  a  1-kHz  sine  wave  with  a  200- mV 
peak-to-peak  swing  was  connected.  The  macro  in  Appendix  C  running  at  a  sampling 
rate  of  100  MHz  was  used  to  sample  the  data  from  the  A/D  converters. 

2.  Test  Results 

Figure  8  depicts  the  results  of  the  SRC-6E  sampling  a  sine  wave  input  which  was 
saved  as  a  file  and  then  plotted.  Figure  8  depicts  the  first  1000  samples  of  the  500,000 
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samples  taken  and  the  voltage  level  recorded  for  each  sample.  Over  the  500,000  samples 
there  was  a  1.90%  error  rate,  where  an  error  is  any  sampled  voltage  level  outside  the  ex¬ 
pected  input  voltage  range.  In  this  case,  the  expected  voltage  range  was  ±100  mV  .  The 
source  of  this  error  was  not  determined,  as  it  was  not  significant  for  the  purposes  of  this 
thesis.  At  a  sampling  rate  of  100  MHz,  it  was  expected  that  a  single  cycle  of  a  1-kHz 
sine  wave  would  take  100  samples.  This  supposition  was  supported  by  the  findings 
shown  in  Fig.  8. 
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Figure  8.  Sampling  of  a  1-kHz  sine  wave  input  to  the  A/D  converters  and 

sampled  at  a  rate  of  100  MHz. 


Given  the  1.90%  error,  the  sine  wave  was  adequately  sampled  to  reproduce  the 
wave  itself  and  this  test  was  seen  as  a  proof  of  a  functioning  macro  as  well  as  the  A/D 
converters. 

The  sampling  of  the  A/D  converter  signal  was  the  culminating  point  for  the  sig¬ 
nificant  portion  of  the  macro  development  for  this  thesis,  which  started  with  exporting  the 
of  the  SRC  clock  to  the  A/D  converters.  With  the  development  of  a  functioning  sampling 
system,  the  data  collected  must  be  manipulated  in  such  a  way  as  to  produce  accurate  ra¬ 
dar  imagery.  To  do  this,  the  raw,  sampled  radar  signals  must  be  processed  using  basic 
radar  theory,  as  described  in  the  next  chapter. 
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V.  BASIC  RADAR  SIGNAL  GENERATION  THEORY  AND  THE 

AN/SPS-65(V)1 


A.  INTRODUCTION 

Sampling  and  storing  the  I  and  Q  channel  information  was  a  major  portion  of  this 
thesis  work,  as  described  in  Chapter  IV.  With  the  creation  of  an  adequate  sampling  inter¬ 
face  to  the  AN/SPS-65(V)1,  the  next  step  was  to  process  the  data  captured.  This  chapter 
outlines  basic  radar  signal  generation  theory  applicable  to  many  radar  platforms.  Build¬ 
ing  on  this  theory  is  a  detailed  discussion  of  the  AN/SPS-65(V)1  operation 

B.  BASIC  RADAR  IMAGE  GENERATION  THEORY 

A  radar  system  has  two  basic  components,  a  transmitter  and  a  receiver.  The  trans¬ 
mitter  generates  high  power,  short  duration  pulses  which  are  radiated  by  the  antenna. 

Once  transmission  of  the  pulse  ends,  a  sensitive  antenna  mounted  receiver  collects  trans¬ 
mitted  pulse  reflections  for  a  period  of  time.  When  using  a  rotating  antenna,  this  process 
is  repeated  many  times  as  the  antenna  sweeps  through  an  entire  revolution. 

From  the  transmitter,  the  high  energy  pulse  travels,  for  the  purposes  of  this  thesis, 

at  the  speed  of  light,  c  =  3.0x1 08  m/s.  As  the  pulse  collides  with  objects  along  the 
transmission  path,  some  of  the  pulse  energy  is  reflected  off  the  object.  A  portion  of  this 
reflected  energy  travels  back  along  the  transmission  path  and  is  detected  by  the  receiver. 
This  detected  signal  is  then  sampled,  stored,  and/or  processed. 

The  distance,  d,  that  the  object  is  from  the  radar  can  be  determined  by  the  for¬ 
mula: 

d  =  — .  (5.1) 

2 

The  variable  t  is  the  round  trip  time  of  the  signal. 

This  general  method  was  used  to  generate  a  basic  range  map  of  a  sampled  analog 
signal  coining  from  the  AN/SPS-65(V)1  radar.  Prior  to  discussing  the  signal  processing 
on  the  SRC-6E,  a  few  facts  about  the  radar  system  used  must  be  explored. 
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C.  AN/SPS-65(V)1  AND  RADAR  THEORY 

1.  Basic  Radar  Theory  Applied  to  AN/SPS-65(V)1  Characteristics 

The  AN/SPS-65(V)1  operated  at  a  pulse  repetition  frequency  (PRF)  of  3,064 
transmitted  pulses  per  second.  Each  transmitted  pulse  has  a  width  of  7  ps.  The  transmis¬ 
sion  and  reception  of  the  pulse  occurs  on  a  rotating  antenna,  where  ra  =  4  seconds  per  ro¬ 
tation. 


The  PRF  period,  TPRF ,  the  time  between  pulses,  is  given  by: 


T  = 

1  PRF 


1  1 


PRF  3064 


=  32.637  ps. 


(5.2) 


Using  Eq.  (5.1),  and  inserting  TPRF  for  time,  the  effective  detection  distance  of  the  radar 
is  summarized  in  Table  2.  The  theoretical  range  of  the  signal  is  dther- 


Table  2.  Effective  theoretical  range  of  the  AN/SPS-65(V)1. 


km 

miles 

nautical  miles 

Range 

48.956 

30.43 

26.46 

Given  the  PRF  and  ra  of  the  AN/SPS-65(V)1,  the  total  number  of  pulse  intervals 
per  revolution  (PPR)  is  calculated  by: 

PPR  =  PRF-  ra  =  (3,064)  (4)  =  12,256  pulS6S .  (5.3) 

rev 

2.  AN/SPS-65(V)1  Pulse  Width  and  Timing 

The  AN/SPS-65(V)1  uses  a  trigger  signal  to  initiate  the  transmitted  pulse.  The 
pulse  rate  of  this  signal,  as  described  above,  was  3,064  pulses  per  second  for  all  experi¬ 
ments.  At  the  stall  of,  and  initiated  by,  the  trigger  signal,  the  transmitter  begins  to  trans¬ 
mit  and  the  receiver  turns  off.  The  transmitter  transmits  for  7  ps  ,  after  which  the  trans¬ 
mitter  turns  off  and  the  receiver  turns  on.  After  TPRF ,  the  trigger  signal  goes  high  and  the 

cycle  repeats.  During  this  process,  the  antenna  is  rotating  360°  every  four  seconds.  Thus, 
the  angle  rotated  through  for  a  given  TPRF  is  the  angle  per  pulse  (APP): 

360  360  n  non/I0/  i 

APP  = - = - =  0.0294  / pulse 

PPR  12,256 
24 


(5.4) 


Given  basic  radar  theory  applied  to  the  characteristics  of  the  AN/SPS-65(V)1,  a 
number  of  values  were  determined  throughout  this  chapter.  These  values  are  summarized 
in  Table  3. 


Table  3.  Figures  of  interest  for  Chapl 

ter  V. 

PRF  [Hz] 

ra  [s  per  rev] 

PPR  [pulse/rev] 

Tprf  [ps] 

tfther  [km] 

APP  [2/pulse] 

3,064 

0.25 

12,256 

32.64 

48.96 

0.029 

These  calculated  values  are  used  when  sampling  the  data  with  the  programs  writ¬ 
ten  on  the  SRC-6E.  As  will  be  shown  in  the  next  chapter,  the  values  in  Table  3  are  im¬ 
portant  in  the  creation  of  a  radar  signal  processor. 
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VI.  RADAR  SIGNAL  PROCESSING  WITH  THE  SRC-6E 


A.  INTRODUCTION 

As  shown  in  Chapter  V,  the  analog  radar  signal  is  generated  as  a  result  of  recep¬ 
tion  of  a  reflected  radar  pulse.  The  received  analog  radar  signal  is  then  fed  through  a  se¬ 
ries  of  amplifiers  and  filters  and  presented  in  analog  form  on  the  I  and  Q  channels  for 
digital  conversion  [3],  The  I  and  Q  channel  voltage  level  are  then  digitized  into  a  series 
of  8-bit  digital  signals  at  a  rate  of  100  MHz.  The  A/D  converters,  in  turn,  present  the 
digital  data  signals  to  the  SRC-6E  general-purpose  I/O  port.  The  macros  described  in 
Chapter  IV  read  the  digital  signals  in  at  100  MHz  and  present  the  signals  as  a  variables 
for  storage  and/or  processing. 

At  this  point,  the  processing  of  the  retrieved  radar  signals  begins.  The  objective 
of  this  chapter  is  to  describe  the  radar  signal  processing  methodologies  explored  in  the  at¬ 
tempts  to  generate  a  range  map.  This  chapter  will  examine  the  sampling  rate  used,  the  re¬ 
sultant  data  rate  incurred,  the  physical  characteristics  of  the  SRC-6E,  and  the  program¬ 
ming  means  used  to  process  the  radar  signal  given  the  SRC-6E  environment. 

B.  SAMPLING  OF  THE  ANALOG  I  CHANNEL  SIGNALS 

To  build  a  range  map,  it  is  only  necessary  to  analyze  information  from  one  of  the 
channels.  As  such,  in  the  remainder  of  this  discussion  we  focus  onprocessing  the  I  chan¬ 
nel  information  exclusively. 

1.  Sampling  Rates  of  the  A/D  Converter  and  SRC-6  E 

As  mentioned  before,  the  A/D  converters  operate  off  the  digital  clock  from  the 
SRC-6E.  The  clock  rate  output  of  the  SRC-6E  is  100  MHz.  The  A/D  converters  sample 
the  radar  output  (I  and  Q  channels)  at  the  SRC -provided  clock  rate  of  100  MHz  [2],  The 
data  from  the  A/D  converters  is  brought  into  the  SRC  via  the  macro  interface  described  in 
Chapter  IV.  The  data  presented  by  the  macros  can  be  sampled  by  the  MAP  functions  at  a 
rate  of  up  to  100  MHz.  It  is  important  to  distinguish  between  the  sampling  rate  and  the 
storage  rate. 
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2.  Ideal  Sampling  and  Effects  on  Data  Rates  and  Storage  Requirements 

Referring  back  to  Chapter  V,  the  radar  signal  is  divided  into  a  series  of  distinct 

time  periods.  Within  each  time  period,  TPRF,  a  7-ps  pulse  is  transmitted  and  then  there  is 
a  period  of  tune  where  the  receiver  collects  reflected  energy  from  the  pulse.  As  shown  in 
Eq.  (5.2),  the  total  time  takes  32.637  ps  and  is  delimited  by  trigger  signals.  There  are 
32,637  samples  per  pulse  (SPP)  repetition  as  calculated  by: 

SPP  =  (32.637  ps)  (100  MHz)  =  32,637.  (6.1) 

As  the  radar  output  is  being  sampled  at  100  MHz,  the  range  bin  of  each  sample  represents 
a  distance  of  1.5  m  as  shown  by: 

Range  Bin  =  ^rher  =  =  15  m  ( 6.2 ) 

SPP  32,637 

The  voltage  level  of  the  sampled  signal  is  represented  as  eight  bits.  As  such,  it  is 
possible  to  determine  the  ideal  data  rate,  which  is  32,637  bytes  per  pulse.  This  equates  to 
a  data  rate  of  ~100  MBps,  given  the  PRF.  To  store  eveiy  sample  at  the  ideal  rate  for  one 
revolution  of  the  antenna,  it  would  take  400  MB  of  storage  capacity. 

3.  SRC-6E  Available  Data  Rates  and  Storage  Capacity 

The  macro  provides  the  sampled  data  to  a  MAP  function  eveiy  clock  period. 
Therefore,  the  data  either  has  to  be  stored  or  processed  before  being  lost  There  are  two 
possible  storage  locations  within  the  SRC-6E,  the  microprocessor  side  or  the  MAP  side. 

To  store  information  to  the  microprocessor,  the  data  must  be  streamed  via  a  DMA 
operation  across  the  internal  SNAP  port.  Unfortunately,  the  sustained  data  transmission 
speed  of  the  SNAP  port  from  MAP  to  microprocessor  is  195  MBs  [7],  While  this  is  ade¬ 
quate  for  just  I  primary  channel  data,  it  would  be  insufficient  for  the  transmission  of  I 
secondary  and  Q  primary  and  secondary  information  which  would  quadruple  the  data 
bandwidth.  In  addition,  streaming  the  data  in  this  manner  would  bypass  the  potential  ad¬ 
vantages  of  performing  the  processing  on  the  FPGA  in  the  MAP. 

This  leaves  the  MAP  for  the  storage  and/or  processing  of  the  I  primary  channel 
information.  As  described,  a  single- side  FPGA  within  the  MAP  has  24  MB  of  memory 
divided  evenly  between  six  banks  of  memory.  In  order  to  use  the  parallel  processing  ca¬ 
pabilities  of  the  MAP,  only  two,  or  ideally,  one  bank  of  memory  should  be  used  to  store 
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data  at  a  time.  This  leaves  the  remaining  banks  of  memory  free  to  process  previously 
stored  data  or  for  the  transfer  of  data  to  the  microprocessor  concurrent  to  memory  storage 
from  the  macro.  This  self-imposed  restriction  leaves  one  4- MB  bank  of  memory  avail¬ 
able  for  the  storage.  At  SPP  from  Eq.  (6.2),  it  would  take  approximately  122  pulses  to 
fill  a  bank  of  memory.  Using  Eq.  (5.4),  for  the  APP,  this  would  be  a  radar  sweep  of 
~3.52.  Clearly  this  is  inadequate  when  attempting  to  generate  a  range  map  for  an  entire 
radar  sweep  of  360s. 

C.  STRATEGIES  TO  MINIMIZE  STORAGE  REQUIREMENTS  OF  THE 

RADAR  IMAGE 

In  the  course  of  this  thesis,  two  basic  strategies  were  considered  in  minimizing  the 
storage  requirements  while  retaining  the  capacity  for  parallel  execution.  Those  strategies 
were  centered  on  limiting  the  number  of  samples  stored  and,  paradoxically,  not  storing 
the  samples  at  all.  The  next  two  sections  discuss  these  strategies  in  detail. 

1.  Limiting  the  Number  of  Samples  Stored 

The  main  focus  of  this  strategy  was  to  maintain  a  storage  rate  of  100  MHz  but 
limit  the  range  of  samples  actually  stored.  The  overall  goal  of  this  approach  was  to  limit 
the  number  of  samples  stored  to  500,000  samples,  the  approximate  number  of  elements  in 
a  single  bank  of  OBM.  By  storing  several  samples  in  a  single  array  element,  data  pack¬ 
ing,  eight  8-bit  words  were  stored  in  a  single  64-bit  element.  Using  data  packing,  it 
would  be  possible  to  store  up  to  4M  samples.  Due  to  coding  complexity  and  time  con¬ 
straints,  the  data  packing  approach  was  not  explored.  There  were,  however,  a  number  of 
approaches  considered  that  limit  the  number  of  samples  stored. 

a.  Limit  the  Range  of  Sampling 

Instead  of  storing  the  entire  effective  range  of  the  radar,  as  shown  in  Table 
3,  it  was  thought  that  by  limiting  the  range,  the  storage  requirements  would  be  mini¬ 
mized.  To  accomplish  this,  only  a  limited  number  of  samples  would  actually  be  stored 
from  every  pulse 

If  only  one  sample  per  pulse  per  revolution  of  the  antenna  was  stored, 
12,256  elements  of  memory  would  be  required.  If  40  samples  per  pulse  per  revolution 
were  stored,  it  would  require  490,024  storage  elements,  slightly  less  than  the  500k  ele- 
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ments  per  bank.  Using  data  packing,  it  would  be  possible  to  store  320  samples  per  pulse. 
Each  stored  sample,  per  Eq.  (6.2),  represents  1.5  m  in  range.  With  data  packing,  the 
stored  range  of  the  radar  would  be  480  m  and  without  packing,  60  m.  This  method  se¬ 
verely  limited  the  stored  range  of  radar  signals  and  was  abandoned  as  a  viable  approach. 

b.  Limit  the  Arc  Stored 

As  shown  in  Eq.  (5.4),  each  pulse  represents  -0.03s  along  the  entire  sweep 
of  the  radar  antenna.  By  chaining  together  PPR,  the  entire  360s  image  is  generated.  By 
skipping  pulses,  the  entire  effective  range  could  be  stored  while  minimizing  the  storage 
capacity  required.  Each  pulse  requires  SPP  number  of  elements  per  Eq.  (6.1).  hi  terms 
of  storage,  120  pulses  with  data  packing,  and  15  without  data  packing,  could  be  stored  in 
a  single  bank  of  OBM.  Given  pulse  storage  skipping,  each  stored  pulse  would  represent 
a  3Q-  or  242-  sweep  of  the  antenna  with  respect  to  data  packing.  At  best,  this  is  a  loss  in 
arc  resolution  of  100  times  that  provided  by  the  AN/SPS-65.  This  approach  was  also 
abandoned  due  to  the  limited  arc  resolution. 

2.  Storing  a  Representation  of  the  Sampled  Signal 
Limiting  the  number  of  samples  stored  via  limiting  the  range,  arc  resolution,  or 
some  combination  was  not  viable  when  attempting  to  compress  the  data  into  one  un¬ 
packed  bank  of  OBM.  An  alternate  strategy  is  to  store  a  representation  of  the  signals 
rather  than  each  signal  value  [11]. 

a.  Averaging  a  Range  of  Sampled  Values 

This  method  focused  on  simply  averaging  the  returned  voltage  levels  over 
a  number  of  samples  and  storing  the  average.  To  represent  <ither  for  360s  in  a  single 
OBM,  it  would  require  the  averaging  blocks  of  800  samples.  The  majority  of  the  sam¬ 
pled  values  were  at  or  near  0  V  and  reflected  images  were  typically  small  in  scale  with 
values  around  20  mV. 

Using  averaging,  the  majority  samples  would  tend  to  dominate  the  results. 
This  tended  to  drive  the  average  value  below  the  noise  threshold  where  it  was  difficult  to 
determine  whether  there  was  an  actual  reflected  radar  signal.  Per  Eq.  (6.2),  a  returned  ra¬ 
dar  image  would  need  to  be  at  least  600  m  long  before  significantly  affecting  the  radar 
image  using  averaging.  Recalling  the  purpose  of  the  AN/SPS-65 (V)l,  averaging  would 


30 


provide  adequate  detection  of  missiles  and  aircraft  exceeding  600  m  in  length  Without 
reference  to  actual  threat  sizes,  it  was  quickly  determined  that  averaging  was  an  inade¬ 
quate  method. 

b.  Summing  a  Range  of  Samples  for  Storage 

Instead  of  storing  the  average  value,  the  sum  of  values  was  stored.  By 
adding  together  700  samples,  it  was  nearly  possible  to  store  the  complete  range  for  one 
full  rotation  of  the  antenna  in  a  single,  unpacked  bank  of  OBM.  A  block  of  700  samples 
represents  7  ps  of  time  which  corresponds  to  1.05  km  per  Eq.  (5.1).  By  summing  the 
sampled  values,  actual  targets  were  not  lost  in  the  sampling  method  as  was  with  the  aver¬ 
aging  method. 

Summing  700  samples  alone  was  not  adequate  to  meet  the  unpacked  OBM 
bank  size  requirement.  Each  pulse  is  sampled  SPP  times.  As  sampling  is  continuous 
throughout  this  process,  the  first  700  samples  after  the  PRF  trigger  signal  do  not  contain 
useful  information.  This  corresponds  to  the  transmission  of  pulse  in  which  the  receiver  is 
shut  off.  This  leaves  SPP  -  700  =  32,637  -  700  =  31,937  samples  of  interest  to  represent 

radar  returns  between  the  PRE  trigger. 

By  summing  every  700  samples,  there  are  45.62  sample  blocks  per  pulse. 
This  means  there  would  be  ~46  elements  to  store  for  each  pulse  of  the  radar.  Given  the 
PPR,  it  would  take 45.62  PPR  -559,119  samples  to  represent  one  revolution  worth  of 
data.  This  is  clearly  too  large  to  fit  in  an  unpacked  single  bank  which  at  maximum 
( Mobm ),  523,776  64- bit  elements  long  [6]. 

Given  Mobm/PPR  =  42.74  «  42 ,  42  is  the  maximum  number  of  sample 
blocks  per  pulse  that  would  fit  in  an  unpacked  OBM  bank.  At  700  samples  per  block, 
each  pulse  would  be  represented  by  29,400  samples  at  100  MHz.  The  effective  range  of 
this  storage  system  would  be  44.1  km  for  an  entire  revolution  of  the  antenna  and  an  arc 
resolution  of  -0.03°  Using  this  process  for  storing  the  radar  return  information,  it  is  pos¬ 
sible  to  represent  radar  returns  from  1.05  to  45.15  km.  Table  4  shows  these  values  and 
then  compares  them  to  the  theoretical  ranges  from  Table  3.  Comparing  this  methodology 
to  the  theoretical  range,  there  is  a  difference  of  4.86  km.  This  methodology  is  appeared 
to  be  a  likely  candidate  for  storage  of  the  radar  range  information. 
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Table  4.  Effective  range  using  summation  compared  to  theoretical 


range. 


km 

miles 

Nautical  Miles 

Start 

1.05 

0.65 

0.57 

End 

45.15 

28.06 

24.41 

44.10 

27.41 

23.84 

Theory 

48.96 

30.43 

26.46 

Difference 

4.86 

3.02 

2.62 

The  expressed  goal  of  this  chapter  was  an  examination  of  the  methodology 
used  to  generate  a  range  map  from  the  generated  radar  returns.  In  the  course  of  this  ob¬ 
jective,  the  ideal  sampling  rate  was  shown  to  exceed  the  storage  capacity  in  the  SRC-6E. 
Two  strategies  to  circumnavigate  this  limitation  were  explored.  The  resulting  strategy 
stores  a  radar  image  in  such  a  way  to  allow  for  parallel  processing  within  the  FPGA. 

This  final  method  coupled  summation  of  samples  with  range  limitation  The  following 
chapter  is  an  examination  of  code  and  the  data  collected  using  derivatives  of  the  summa¬ 
tion/range  restriction  technique. 
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VII.  PROCESSED  RADAR  SIGNALS  AND  ANALYSIS  OF 

RESULTS 


A.  INTRODUCTION 

The  last  chapter  examined,  in  detail,  the  various  factors  which  shaped  the  radar 
signal  processing  approach.  This  chapter  discusses  methods  used  to  process  the  radar 
signals  from  the  ANSPS-65(V)1.  The  methods  used  here  divided  the  signal  processing 
between  three  separate  coding  environments:  the  MAP  functions,  the  SRC  microproces¬ 
sor,  and  MATLAB®  code.  The  goal  of  the  initial  attempt  was  two -fold,  to  verify  correct 
operation  of  the  sample- and- store  system  and  to  validate  the  coded  processing  environ¬ 
ment  in  conjunction  with  a  ‘live  feed’  from  the  ANSPS-65(V)1. 

B.  CODE  USED  TO  STORE  AND  PROCESS  RADAR  RETURNS 

The  programming  code  used  to  sample-and-store  the  raw  data  was  done  within  a 
MAP  function.  The  stored  data  was  then  transferred  to  the  microprocessor  side  of  the 
SRC-6E  where  limited  processing  occurred  prior  to  being  saved  as  a  text  file.  The  text 
file  was  imported  into  MATLAB  for  static  processing. 

This  coding  method  departs  slightly  from  the  methods  described  in  Chapter  VI. 
The  departure  is  due  to  the  goals  of  the  initial  coding  test,  to  prove  the  sampling  system 
works  and  perform  limited  radar  processing  on  stored  data.  In  this  manner,  the  code  was 
not  optimized  with  respect  for  parallel  processing  on  the  FPGAs. 

The  sampling  of  data  from  the  A/D  converters  occurred  via  a  macro  (see  Chapter 
IV)  called  by  a  MAP  function  described  below.  The  MAP  function  was  called,  in  turn, 
by  a  microprocessor  function  which  stored  the  data  returned  by  the  MAP  function  to  a 
file. 

Figure  9  shows  an  abbreviated  version  of  the  C- language  program  used  on  the 
microprocessor- side  of  the  SRC-6E  to  initiate  the  sample-and-store  process.  The  com¬ 
plete  and  actual  code  used  can  be  found  in  Appendix  D,  which  contains  SRC-6E- specific 
code.  This  program  defines  several  arrays  and  then  calls  a  MAP  function,  STRBITIN,  to 
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fill  the  arrays  with  sampled  data.  The  returned  data  is  then  translated  from  A/D  converter 
values  to  actual  voltage  levels  as  described  in  Eq.  (2.1).  This  converted  data  is  then 
saved  in  a  file  ‘output.txt’. 

#include<stdio . h> 

void  strbitin  ();  //  Function  Definition 

int  main  ( )  { 

FILE  *outfilep; 

outfilep  =  fopen  (" ./output.txt", ”w") /  //  Output  file  name 

int  i;  //  Loop  counter 

long  long  *Ipri;  //  I  primary  channel  data 

long  long  *Isec;  //  I  secondarychannel  data 

long  long  *Qpri;  //  Q  primary  channel  data 

long  long  *Qsec;  //  Q  primary  channel  data 

long  long  *PRF;  //  PRF  data 

//  Call  to  the  MAP  function:  start  bit  input 
strbitin  (Ipri,  Isec,  Qpri,  Qsec,  PRF) ; 

//  Print  the  results  in  the  arrays  to  a  file 

int  tip,  tls,  tQp,  tQs; 

for  (i=0; i<MAX_OBM_SIZE; i++)  { 

tip  =  (Ipri[i]  -128)*  1.95;  //  Voltage  conversion  scale 

tls  =  (Isec[i]  -128)*  1.95;  //  Voltage  conversion  scale 

tQp  =  (Qpri[i]  -128)*  1.95;  //  Voltage  conversion  scale 

tQs  =  (Qsec[i]  -128)*  1.95;  //  Voltage  conversion  scale 

fprintf  (outfilep,  "%-7d  %-4d  %-4d  %-4d  %-4d  %-411d\n,,/ 
i,  tip,  tls,  tQp,  tQs,  PRF[i]);  //Print  arrays 

}  //  End  for  (i=0;i<MAX  . 

return ( 0 ) ; 

}  / /  End  main . c 

Figure  9.  Code  used  in  main.c. 

Figure  10  shows  a  compressed  version  of  the  code  presented  in  Appendix  D.2.  In 
this  MAP  function,  the  macro  ‘bitin’  is  called.  Bitin  is  the  macro  developed  in  Chapter 
IV.  This  macro  returns  one  32-bit  integer,  radar Sig,  and  one  1-bit  integer,  PRF.  The 
variable  radarSig  is  the  composed  of  four  8-bit  integers,  each  representing  the  I  and  Q 
primary  and  secondary  channels.  PRF  is  the  signal  that  originates  from  the  AN/SPS- 
65(V)1,  indicating  the  triggered  beginning  of  a  radar  pulse  as  described  in  Chapters  II 
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and  V.  The  MAP  function,  STRBITIN,  collects  data  from  the  macro,  unpacks  the  data, 
and  stores  it  in  a  separate  array.  As  shown  in  the  Appendix  D.2,  each  array  is  actually  a 
bank  of  OBM  memory. 

/********************************************************************** 

*  Thesis:  Interface  32  bits  input  to  main.c,  four  8-bit  and  one  1-bit 

*  variable  out  to  calling  program. 

* 

*  Macro  Called:  bitin.  This  macro  samples  33  data  lines  and 

*  returns  the  values  to  this  function. 

* 

*  Programs  calling  this  function: 

*  Pass  by  reference  five  64-bit  integer  element  length  arrays 

*  -500,000  elements  long. 

* 

*  This  function  then  splits  out  the  32  bit  input  returned  by  the 

*  macro  bitin  into  four  arrays  where  each  array  represents : 

*  A  =  I  primary  channel  information  =  bits  7 : 0 

*  B  =  I  secondary  channel  information  =  bits  15 : 8 

*  C  =  Q  primary  channel  information  =  bits  23:16 

*  D  =  Q  secondary  channel  information  =  bits  31:24 

*  E  =  PRF  information  from  a  separate  variable 

*  When  an  array  is  filled  to  MAX_OBM_SIZE ,  the  OBM  banks  are 

*  passed  back  to  the  calling  function. 

* 

void  strbitin  (long  long  A[],  long  long  B[],  long  long  C[], 

long  long  D[],  long  long  E [ ] )  { 

int  radarSig,  PRF,  i;  //  storage  var,  stor  var,  counter 

out  =  55;  //  Initialize  out 

for  (i=0; i<MAX_OBM_SIZE; i++)  { 

bit in ( &radarSig,  &PRF) ;  //  Get  data  from  pin(s) 

//  Variable  Out  packed  with  four  variables.  Unpacking  here. 
A[i]  =  radarSig  &  OxOOOOOOOOOOOOOOf f ;  //  I  prim 

B[i]  =  (radarSig  &  OxOOOOOOOOOOOOf f 00 )  >>  8;  //  I  sec 

C[i]  =  (radarSig  &  OxOOOOOOOOOOf f 0000 )  >>  16;  //  Q  prim 

D[i]  =  (radarSig  &  OxOOOOOOOOff 000000 )  >>  24;  //  Q  sec 

E [ i ]  =  PRF;  //  PRF 

}  //  End  for  (i=0;i<MAX  .  .  . 

}  //  End  strbinin 

Figure  10.  MAP  function  STRBITIN  used  to  store  data  from  the  macro 

bitin. 

The  data  stored  by  mam  was  then  imported  into  MATLAB.  The  complete  code 
for  this  is  included  in  Appendix  D.3.  The  MATLAB  code  performed  the  basic  process- 
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ing  described  in  Chapter  VI,  Section  C.2.b,  without  the  range  limitation.  Also,  the  plot  in 
Fig.  11  was  generated  via  MATLAB. 


C.  TESTING  OF  CODE  AND  GENERATED  IMAGE 

With  the  code  described  in  the  section  above,  all  the  necessary  components  to  test 
the  SRC -to- radar  interface  were  implemented  and  ready  for  evaluation 

1.  Test  Setup 

a.  AN/SPS-65(V)1  System  Setup 

The  AN/SPS-65(V)1  antenna  returned  a  signal  along  a  fixed  azimuth  ap¬ 
proximately  true  north  of  the  antenna  position.  The  only  values  returned  to  the  I  and  Q 
channels  were  readings  along  this  fixed  azimuth. 

b.  A/D  Converter  Setup 

An  A/D  converter  was  connected  to  the  radar  I  channel  provided  by  the 
AN/SPS-65(V)1.  The  converter  only  provided  the  8-bit  I  primary  channel  data.  The 
A/D  board  was  physically  connected  to  the  SRC  via  the  general-purpose  I/O  port  within 
the  SRC-6E. 

c.  SRC  and  Signal  Processing  Setup 

Using  the  macro  developed  in  Chapter  IV  and  the  code  discussed  in  this 
chapter,  an  executable  program  was  run  several  times.  Each  time,  a  collection  of  data 
samples  were  stored  for  later  processing.  A  series  of  approximately  16  transmit/receive 
cycles  (pulse  interval)  were  recorded  and  processed  along  the  fixed  azimuth  path.  Since 
this  setup  does  not  store  an  entire  antenna  revolution  worth  of  data,  there  were  no  range 
restrictions  imposed  by  the  processing  method.  Recorded  ranges,  using  this  method, 
should  correspond  to  the  values  shown  in  Table  3. 

2.  Results 

An  analysis  of  the  output  file  directly  shows  that  there  were  32,639  samples  be¬ 
tween  the  stall  of  trigger  signals.  Compared  to  SPP,  this  is  a  sampling  error  of  0.006% 
from  the  expected  SPP.  The  sampling  system  closely  matched  the  PRF  signal  expecta¬ 
tions. 

Figure  1 1  shows  a  plot  of  the  processed  information  as  captured  with  the  system. 
The  plot  is  the  summation  of  voltage  values  returned  by  the  radar  system  compared  to  the 
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range  in  kilometers.  In  addition,  the  summation  of  the  trigger  signal,  PRF,  was  plotted. 
When  the  PRF  transitions  from  low  to  high,  0  to  20,000,  it  is  an  indication  of  the  begin¬ 
ning  of  a  transmitted  pulse  by  the  AN/SPS-65(V)1.  From  there,  the  range  calculations 
began 


x  -|q4  AN/SPS-65  Radar  Return  via  SRC-6E  processor 


Figure  11.  Processed  radar  image. 

At  approximately  40  km,  there  is  the  beginning  of  a  large  radar  return.  Figure  12 
shows  the  distance  from  the  antenna  position  to  the  Santa  Cruz  Mountain  range.  This 
distance  is  shown  to  be  approximately  40  km,  suggesting  that  this  is  the  source  of  the  re¬ 
turn.  (Figure  12  was  generated  with  the  Department  of  Defense  geological  information 
system  standard  program  ESRI®  ArcMap,  version  8.3,  and  data  generated  by  the  Mon¬ 
terey  Bay  Aquarium  Research  Institute  with  the  assistance  Arlene  Guest  Senior  Lecturer, 
Department  of  Oceanography,  Naval  Postgraduate  School.) 
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Figure  12.  Range  from  the  Naval  Postgraduate  School  (NPS)  to  Santa 

Cruz  Mountains. 

The  apparent  success  served  as  the  capstone  to  the  material  of  this  chapter  which 
outlined  the  programs  developed  to  process  a  radar  signal.  Also,  the  radar  signal  process¬ 
ing  was  tested  and  evaluated  against  real  world  data.  The  results  of  which  satisfied  the 
expressed  objectives  of  this  thesis  work  as  noted  in  the  conclusion,  Chapter  VIII. 
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Yin.  CONCLUSION 


A.  SUMMARY 

The  objective  of  this  thesis  was  to  build  a  software  interface  to  the  AN/SPS 
65(V)1  that  would  allow  for  the  limited  processing  of  radar  signals.  The  intricacies  of  the 
various  systems  used,  the  radar,  the  A/D  converters,  and  the  SRC-6E,  were  discussed  in 
order  to  provide  a  basis  for  understanding  the  thesis  work. 

The  thesis  work  focused  on  three  major  constructs:  macro  development,  radar  the¬ 
ory  and  image  processing,  and  programming  and  testing  a  radar  processing  device.  The 
macro  development  progressed  sequentially  along  two  lines,  clocking  and  data  input. 
Eventually,  the  two  lines  of  development  were  merged  to  form  a  cohesive  macro  which 
provided  a  unified  software  interface  to  the  A/D  converters  for  later  radar  processing. 

The  radar  processing  research  explored  a  variety  of  processing  options.  For  vari¬ 
ous  reasons,  as  described  above,  a  number  of  the  processing  options  were  abandoned.  A 
suitable  processing  method  was  discovered  and  used  as  a  basis  for  the  developed  soft¬ 
ware  system. 

The  programmed  radar  processor  spamied  three  environments:  the  SRC  MAP 
function,  microprocessor- based  processing,  and  a  third  program  that  provided  a  static  dis¬ 
play  of  the  radar  signal.  By  integrating  the  various  components,  a  radar  image  was  sam¬ 
pled,  stored,  processed  and  displayed.  As  shown  in  Chapter  VII,  the  system  implemented 
accurately  reported  on  received  radar  returns. 


B.  SUGGESTED  FUTURE  WORK 

While  this  thesis  work  completed  the  objectives,  there  were  still  uncompleted  pro¬ 
ject  goals.  Namely,  sophisticated  radar  processing  software  was  not  implemented  and  the 
potential  advantages  of  reconfigurable  computing  were  not  demonstrated  fully  as  outlined 
in  the  project  objectives. 

The  software  developed  here  was  simply  a  tool  to  prove  or  disprove  the  correct 


functioning  of  the  A/D  converters,  the  SRC-6E  general-purpose  I/O  ports,  macros,  and 

associated  software  to  sample  and  store  radar  signal  data.  The  implemented  software 
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lacks  the  sophistication  of  modem  radar  signal  processing  systems.  The  system  built  can 
be  greatly  unproved  to  provide  a  robust  suite  of  radar  processing  techniques. 

The  system  implemented  in  this  thesis  did  not  fully  demonstrate  the  potential  ad¬ 
vantages  that  reconfigurable  computing  is  reported  to  offer.  It  is  possible  that  the  system 
developed  could  process  not  only  one  type  of  radar,  but  multiple  radar  systems  in  a  nearly 
simultaneous  manner.  The  feasibility  of  this  supposition  is  one  which  could  be  further 
explored  by  harnessing  the  inherent  parallelism  that  a  reconfigurable  computing  platform 
offers.  Chapter  VI  provides  a  possible  framework  from  which  that  research  could  start. 

Despite  the  limitations  described  in  this  section,  a  viable  software  interface  to  a 
radar  system  was  developed  and  tested.  The  skills  called  upon  to  do  this  encompassed: 

•  General  circuit  theory  and  design. 

•  Logic  circuit  theory  and  desiga 

•  Familiarization  with  several  programming  languages  (C,  VHDL, 
MATLAB). 

•  Basic  and  advanced  programming  topics  such  as  function  calls  and  paral¬ 
lel  processing. 

•  Basic  radar  theory  and  desiga 

•  Basic  radar  processing. 

•  Signal  processing. 

•  Timing  analysis  of  circuits,  logic,  and  programmed  code. 

•  Thorough  working  knowledge  of  the  general  reconfigurable  computing 
platform  used. 

•  Working  knowledge  of  logic  circuit  design  tools. 

The  suggested  future  work  would  require,  in  addition  to  this  skill  set,  an  interme¬ 
diate  understanding  of  signal  processing  and  radar  theory. 
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APPENDIX  A:  TRADEMARKS 


Several  terms  used  throughout  this  thesis  are  trademarked.  This  appendix  is  a  list 
of  trademark  terms  used  in  this  document. 

Intel  ’  is  a  registered  trademark  of  the  hitel  Corporation. 

ISE,  or  Integrated  Software  Environment,  is  a  trademark  of  Xilinx,  hie. 

MAP®  is  a  registered  trademark  of  SRC  Computers,  hie. 

MATLAB®  is  a  registered  trademark  of  The  Mathworks,  hie. 

SNAP™  is  a  trademark  of  SRC  Computers,  Inc. 

Virtex®-II  is  a  registered  trademark  of  Xilinx,  Inc. 

Xilinx®  is  a  registered  trademark  of  Xilinx,  Inc. 
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APPENDIX  B:  CONNECTIVITY  DIAGRAMS 


The  following  appendix  is  a  copy  of  the  pin- out  configuration  of  the  Xilinx  Virtex 
II  showing  the  pad  names  and  the  respective  connections  and  name  on  the  A/D  boards 
provided.  The  first  table  is  a  connectivity  diagram  from  the  perspective  of  the  physical 
layout  of  the  pins.  The  second  table  rearranges  the  information  into  a  data  view  perspec¬ 
tive.  Both  tables  contain  essentially  the  same  information,  but  in  views  that  proved  use¬ 
ful  during  the  programming  and  configuration  portions  of  the  thesis. 


Table  5.  Physical  view  of  the  pin-out  connections. 


Mict or /Physical  View 

Breakout 

Mict or 

Xilinx 

Breakout 

Mictor 

Xilinx 

Board 

Pin 

Pad 

Board 

Pin 

Pad 
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1 

U12 
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58 

FI 
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2 

T12 

D58 

59 

Gl 

D02 

3 

M2 

D59 

60 

G5 

D03 

4 

N2 
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61 

H5 

D04 

5 

Rll 

D61 

62 

K8 

D05 

6 

Til 

D62 

63 

J8 

DO  6 

7 

P  8 

D63 

64 

F3 

D07 

8 

N8 

D64 

65 

G3 

D08 

9 

M3 

D65 

66 

H7 

DO  9 

10 

N3 
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67 

H6 
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11 

M5 
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68 
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12 

N5 

D68 

69 
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13 

RIO 
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70 
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D13 

14 

P10 

D70 

71 

F2 

D14 

15 

K1 

D71 

72 

F5 

D15 

16 

LI 

VALO 

73 

G6 

D16 

17 

L4 

FULL 

74 

Mil 

D17 

18 

M4 

VALl 

75 

L12 

D18 

19 

P  9 
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76 

E4 

Dl  9 

20 

N9 

VAL3 

77 

F4 

D20 

21 

L3 
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78 

El 

D21 

22 

L  6 

NC  1 

79 

F20 

D22 

23 

M6 

SPRO 

80 

NOT  CONN 

D23 

24 

R12 

SPRl 

81 

D2 

D24 

25 

P12 

SPR2 

82 

E3 

D25 

26 

J2 

SPR3 

83 

B4 

D26 

27 

K2 

SPR4 

84 

C4 

D27 

28 

J4 

SPR5 

85 

C  6 

D28 

29 

K4 

SPR6 

86 

C5 

D29 

30 

M8 
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87 

E8 
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Mict or /Physical  View 


Breakout 

Mictor 

Xilinx 

Breakout 

Mictor 

Xilinx 

Board 

Pin 

Pad 

Board 

Pin 

Pad 

D30 

31 

L8 

SPR8 

88 

F8 

D31 

32 

HI 

IDAT 

89 

A5 

D32 

33 

J1 

ICLK 

90 

A4 

D33 

34 

L7 

DCLK 

91 

B  6 

D34 

35 

M7 

I -DO 

92 

B5 

D35 

36 

Pll 

I  — D 1 

93 

Hll 

D36 

37 

Nil 

PRST 

94 

H12 

D37 

38 

Dl 

MRST 

95 

C8 

D38 

39 

F19 

PRO 

96 

Cl 

D39 

40 

NOT  CONN 

PRl 

97 

E7 

D40 

41 

K5 
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98 
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42 
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99 
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43 

K6 
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D43 

44 

N10 
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NOT  CONN 

D44 

45 

M10 

BNKl 
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NOT  CONN 

D45 

46 

H3 

BNK2 

103 

J10 

D46 

47 

J3 

BNK3 

104 

H10 

D47 

48 

G4 

SEGO 

105 

Jll 

D48 

49 

H4 

SEG1 

106 

G10 

D49 

50 

M9 

SEG2 

107 

G9 

D50 

51 

L  9 

SEG3 

108 

F  9 

D51 

52 

G2 

NC  2 
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NOT  CONN 

D52 

53 

H2 

NC  3 
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NOT  CONN 

D53 

54 

J7 

NC  4 
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D54 

55 

K7 

NC  5 
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NOT  CONN 

D55 

56 

L10 
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D56 

57 

K9 

MST  CLK 

114 

NOT  CONN 
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Table  6.  Data  view  of  the  pin-out  configuration. 
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16 
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21 
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23 
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25 
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F3 
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APPENDIX  C :  MACRO  DEVELOPED 


Chapter  IV  outlined  the  creation  of  a  macro  which  would  sample  the  signals  pro¬ 
vided  by  the  A/D  converters.  What  follows  is  a  series  of  schematics  and  VHDL  code 
used  for  the  final  macro  developed. 


This  schematic  is  an  overall  view  of  the  schematic  used.  The  scale  of  this  sche¬ 
matic  is  such  that  not  all  the  details  are  immediately  visible.  The  following  schematics  in 
this  appendix  provide  a  detailed  view  of  the  various  sections. 


Q  Channel 


I  Channel 


Figure  13.  Overview  of  the  macro  developed. 
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Figure  14.  Q  Channel  inputs  and  outputs. 
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Figure  15.  I  channel  inputs  and  outputs. 
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Figure  16.  PRF  signal  input  and  output.  Also  the  output  marker  for  the  I 

and  Q  channels. 


FI  9 


\ 


LOC=F19 


IBUF 

Clock  Into  SRC  from  A/D 


Figure  17.  Data  Ready  Signal  interface. 


50 


GND 


DCM 


Figure  18.  DCM  portion  of  the  macro. 
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--  VHDL  model  created  from  C:\Xilinx\virtex2\data\drawing\ifd.sch  -  Sun 
Jan  30  12:48:11  2005 

library  ieee; 

use  ieee . std_logic_l 1 64 . ALL; 
use  ieee . numeric_std . ALL; 

--  synopsys  translate_of f 

library  UNISIM; 

use  UNISIM . Vcomponents . ALL; 

—  synopsys  translate_on 

entity  IFD_MXILINX_in33  is 

port  (  C  :  in  std_logic; 

D  :  in  std_logic; 

Q  :  out  std_logic) ; 

end  IFD_MXILINX_in33; 

architecture  BEHAVIORAL  of  IFD_MXILINX_in33  is 
attribute  INIT  :  STRING  ; 

attribute  BOX_TYPE  :  STRING  ; 

attribute  IOB  :  STRING  ; 

attribute  IOSTANDARD  :  STRING  ; 

signal  D_IN  :  std_logic; 
signal  XLXN_1  :  std_logic; 
signal  XLXN_2  :  std_logic; 
component  FDCE 

—  synopsys  translate_of f 

generic  (  INIT  :  bit  : =  ’O'); 

—  synopsys  translate_on 

port  (  C  :  in  std_logic; 

CE  :  in  std_logic; 

CLR  :  in  std_logic; 

D  :  in  std_logic; 

Q  :  out  std_logic) ; 

end  component; 

attribute  INIT  of  FDCE  :  COMPONENT  is  "0"; 

attribute  BOX_TYPE  of  FDCE  :  COMPONENT  is  "BLACK_BOX" ; 

component  IBUF 

port  (  I  :  in  std_logic; 

0  :  out  std_logic) ; 
end  component; 

attribute  IOSTANDARD  of  IBUF  :  COMPONENT  is  "LVTTL" ; 
attribute  BOX_TYPE  of  IBUF  :  COMPONENT  is  "BLACK_BOX" ; 

component  VCC 

port  (  P  :  out  std_logic) ; 
end  component; 

attribute  BOX_TYPE  of  VCC  :  COMPONENT  is  "BLACK_BOX" ; 
component  GND 

port  (  G  :  out  std_logic)  ; 
end  component; 

attribute  BOX  TYPE  of  GND  :  COMPONENT  is  "BLACK  BOX"; 
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attribute  IOB  of  I  36 

_15  :  LABEL  is  "TRUE"; 

begin 

I_36_15  :  FDCE 

port  map  (C=>C,  CE= 

=>XLXN_ 

2,  CLR=>XLXN_1,  D=>D_IN,  Q=>Q) ; 

I_36_24  :  IBUF 

port  map  (I=>D,  0=: 

!z; 

H 

1 

Q 

I  36  26  :  VCC 

port  map  (P=>XLXN  ^ 

1) ; 

I_36_29  :  GND 

port  map  (G=>XLXN_] 

L) ; 

end  BEHAVIORAL; 

—  VHDL  model  created  from  in33 

. sch  -  Sun  Jan  30  12:48:11  2005 

library  ieee; 

use  ieee . std  logic  1164.7 

\LL; 

use  ieee . numeric  std. ALL; 

—  synopsys  translate  of: 

- 

library  UNISIM; 

use  UNISIM . Vcomponents . ALL; 

—  synopsys  translate  on 

entity  in33  is 

port  (  Clk 

in 

std  logic; 

DCM  RST 

in 

std  logic; 

FI  9 

in 

std  logic; 

HI 

in 

std  logic; 

J2 

in 

std  logic; 

J4 

in 

std  logic; 

Kl 

in 

std  logic; 

K2 

in 

std  logic; 

K4 

in 

std  logic; 

K9 

in 

std  logic; 

LI 

in 

std  logic; 

L3 

in 

std  logic; 

L4 

in 

std  logic; 

L6 

in 

std  logic; 

L8 

in 

std  logic; 

M2 

in 

std  logic; 

M3 

in 

std  logic; 

M4 

in 

std  logic; 

M5 

in 

std  logic; 

M6 

in 

std  logic; 

M8 

in 

std  logic; 

N2 

in 

std  logic; 

N3 

in 

std  logic; 

N5 

in 

std  logic; 

N8 

in 

std  logic; 

N9 

in 

std  logic; 

P8 

in 

std  logic; 

P  9 

in 

std  logic; 

P10 

in 

std  logic; 

P 12 

in 

std  logic; 
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RIO 

in 

std  logic; 

Rll 

in 

std  logic; 

R12 

in 

std  logic; 

Til 

in 

std  logic; 

T12 

in 

std  logic; 

U12 

in 

std  logic; 

CHAIN_INB_CLK 

out 

std  logic; 

INI 

out 

std  logic  vector  (31  downto  0) 

PRF 

out 

std  logic) ; 

attribute 

LOC 

:  STRING  ; 

attribute 

LOC 

of 

F19 

:  SIGNAL 

is  "  F 1 9  "  ; 

attribute 

LOC 

of 

HI 

SIGNAL 

is  "HI"; 

attribute 

LOC 

of 

J2 

SIGNAL 

is  "J2"; 

attribute 

LOC 

of 

J4 

SIGNAL 

is  " J4 " ; 

attribute 

LOC 

of 

Kl 

SIGNAL 

is  "Kl"; 

attribute 

LOC 

of 

K2 

SIGNAL 

is  "K2 " ; 

attribute 

LOC 

of 

K4 

SIGNAL 

is  "K4 " ; 

attribute 

LOC 

of 

K9 

SIGNAL 

is  " K  9 " ; 

attribute 

LOC 

of 

LI 

SIGNAL 

is  "LI"; 

attribute 

LOC 

of 

L3 

SIGNAL 

is  " L  3 " ; 

attribute 

LOC 

of 

L4 

SIGNAL 

is  " L  4 " ; 

attribute 

LOC 

of 

L6 

SIGNAL 

is  "L6" ; 

attribute 

LOC 

of 

L8 

SIGNAL 

is  "  L  8  " ; 

attribute 

LOC 

of 

M2 

SIGNAL 

is  "M2 " ; 

attribute 

LOC 

of 

M3 

SIGNAL 

is  "M3"; 

attribute 

LOC 

of 

M4 

SIGNAL 

is  "M4 " ; 

attribute 

LOC 

of 

M5 

SIGNAL 

is  "M5"; 

attribute 

LOC 

of 

M6 

SIGNAL 

is  "M6"; 

attribute 

LOC 

of 

M8 

SIGNAL 

is  "M8"; 

attribute 

LOC 

of 

N2 

SIGNAL 

is  "N2 " ; 

attribute 

LOC 

of 

N3 

SIGNAL 

is  "N3 " ; 

attribute 

LOC 

of 

N5 

SIGNAL 

is  "N5" ; 

attribute 

LOC 

of 

N8 

SIGNAL 

is  "N8"; 

attribute 

LOC 

of 

N9 

SIGNAL 

is  "N9" ; 

attribute 

LOC 

of 

P8 

SIGNAL 

is  " P  8 " ; 

attribute 

LOC 

of 

P  9 

SIGNAL 

is  " P  9 " ; 

attribute 

LOC 

of 

P10 

SIGNAL 

is  "PIO"; 

attribute 

LOC 

of 

P12 

SIGNAL 

is  " P 1 2  "  ; 

attribute 

LOC 

of 

RIO 

SIGNAL 

is  "RIO"; 

attribute 

LOC 

of 

Rll 

SIGNAL 

is  "Rll"; 

attribute 

LOC 

of 

R12 

SIGNAL 

is  "R12" ; 

attribute 

LOC 

of 

Til 

SIGNAL 

is  "Til"; 

attribute 

LOC 

of 

T12 

SIGNAL 

is  " T 1 2  "  ; 

attribute 

LOC 

of 

U12 

SIGNAL 

is  "U12"; 

attribute 

LOC 

of 

CHAIN  INB  CLK  :  SIGNAL 

end  in33; 


architecture 

attribute 

attribute 

attribute 

attribute 

attribute 

attribute 

attribute 

attribute 

attribute 


BEHAVIORAL  of  in33  is 

BOX_TYPE 

CLK_FEEDBACK 

CLKDV_DIVIDE 

CLKFX_DIVIDE 

CLKIN_PERIOD 

CLKFX_MULTIPLY 

CLKIN_DIVIDE_BY_2 

CLKOUT_PHASE_SHIFT 

DESKEW  ADJUST 


STRING  ; 
STRING  ; 
STRING  ; 
STRING  ; 
STRING  ; 
STRING  ; 
STRING  ; 
STRING  ; 
STRING  ; 
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attribute  DFS_FREQUENCY_MODE  :  STRING  ; 

attribute  DLL_FREQUENCY_MODE  :  STRING  ; 

attribute  DSS_MODE  :  STRING  ; 

attribute  DUTY_CYCLE_CORRECTION  :  STRING  ; 

attribute  PHASE_SHIFT  :  STRING  ; 

attribute  STARTUP_WAIT  :  STRING  ; 

attribute  HU_SET  :  STRING  ; 

attribute  IOSTANDARD  :  STRING  ; 

signal  LD  :  std_logic; 

signal  XLXN_355  :  std_logic; 

signal  XLXN_356  :  std_logic; 

signal  XLXN_606  :  std_logic; 

component  BUFG 

port  (  I  :  in  std_logic; 

0  :  out  std_logic) ; 

end  component; 

attribute  BOX_TYPE  of  BUFG  :  COMPONENT  is  "BLACK_BOX" ; 

component  OBUF_F_24 

port  (  I  :  in  std_logic; 

0  :  out  std_logic) ; 

end  component; 

attribute  BOX_TYPE  of  OBUF_F_24  :  COMPONENT  is  " BLACK_BOX " 

component  DCM 

—  synopsys  translate_of f 

generic (  CLK_FEEDBACK  :  string  : =  H1X"; 

CLKDV_DIVIDE  :  real  : =  2.000000; 

CLKFX_DIVIDE  :  integer  : =  1; 

CLKIN_PERIOD  :  real  : =  0.000000; 

CLKFX_MULTIPLY  :  integer  : =  4; 

CLKIN_DIVIDE_BY_2  :  boolean  : =  false; 

CLKOUT_PHASE_SHIFT  :  string  : =  "NONE"; 

DESKEW_AD JUST  :  string  :=  "SYSTEM_SYNCHRONOUS 
DFS_FREQUENCY_MODE  :  string  :=  "LOW"; 

DLL_FREQUENCY_MODE  :  string  :=  "LOW"; 

DSS_MODE  :  string  :  =  "NONE"; 
DUTY_CYCLE_CORRECTION  :  boolean  :=  true; 
PHASE_SHIFT  :  integer  :=  0; 

STARTUP_WAIT  :  boolean  :=  false); 

—  synopsys  translate_on 

port  (  CLKFB  :  in  std_logic; 

CLKIN  :  in  std_logic; 

DSSEN  :  in  std_logic; 

PSCLK  :  in  std_logic; 

PSEN  :  in  std_logic; 

PSINCDEC  :  in  std_logic; 

RST  :  in  std_ 

Figure  19.  VHDL  code  of  developed  macro. 
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APPENDIX  D :  CODE  USED  IN  THESIS 


1.  COMPLETE  MAIN.C  SAMPLE  AND  STORAGE  OF  RADAR  SIGNAL 

#include<stdio . h> 

#include<libmap . h>  //  New  lib  to  facilitate  map  calls 
#include  <map . h>  //  New  lib  to  facilitate  map  calls 

void  strbitin  ();  //  Function  Definition 

int  main  ()  { 

FILE  *outfilep; 

outfilep  =  fopen  ( " . /oS30 Jan5M . txt " , "w" ) ;  //  Writing  to  file 

int  nmap,  mapmim, i;  //  New  Number  of  maps,  map  #  to  be  used,  loop 

long  long  *Ipri;  //  I  primary  channel  data 

long  long  *Isec;  //  I  secondarychannel  data 

long  long  * Qp r i ;  //  Q  primary  channel  data 

long  long  *Qsec/  //  Q  primary  channel  data 

long  long  *PRF;  //  PRF  data 


Ipri  =  (long  long*)  Cache_Aligned_Allocate  (MAX_OBM_SIZE*sizeof (int 64_t ) ) ; 

Isec  =  (long  long*)  Cache_Aligned_Allocate  (MAX_OBM_SIZE*sizeof (int 64_t ) ) ; 

Qpri  =  (long  long*)  Cache_Aligned_Allocate  (MAX_OBM_SIZE*sizeof (int64_t ) ) ; 

Qsec  =  (long  long*)  Cache_Aligned_Allocate  (MAX_OBM_SIZE*sizeof ( int 64_t ) ) ; 

PRF  =  (long  long*)  Cache_Aligned_Allocate  (MAX_OBM_SIZE*sizeof ( int 6  4_t )  )  ; 

mapnum  =  0; 

nmap  =  1 ; 

//  allocate  map  to  this  problem.  Get  a  map  ready 
if  (map_allocate  (nmap) )  { 

fprintf  (stdout,  "Map  allocation  f ailed . \n" ) ; 
exit  ( 1 )  ; 

}  / /  End  if  (map  . 

//  Call  to  the  MAP  function:  start  bit  input 
strbitin  (Ipri,  Isec,  Qpri,  Qsec,  PRF,  mapnum) ; 

if  (map_free  (nmap) )  { 

printf  ("Map  deallocation  failed.  \n" ); 
exit  ( 1 ) ; 

}  / /  End  if  (map  . 

//  Print  the  results  in  the  arrays  to  a  file 

int  tip,  tls,  tQp,  tQs; 

for  ( i=0 ; i<MAX_OBM_SIZE; i++)  { 

tip  =  (Ipri  [i]  -128)*  1.95; 
tls  =  (Isec  [i]  -128)*  1.95; 
tQp  =  (Qpri  [ i ]  -128)*  1.95; 
tQs  =  (Qsec  [i]  -128)*  1.95; 

fprintf  (outfilep, "%-7d  %-4d  %-4d  %-4d  %-4d  %-411d\n" , 

i,  tip,  tls,  tQp,  tQs,  PRF[i]);  //Print  arrays 

}  //  End  for  (i=0;i<MAX  .  .  . 

retum(O); 

) 
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MAP  FUNCTION  START  BIT  INPUT 


/********************************************************************** 

*  Thesis:  Interface  32  bits  input  to  main.c,  four  8-bit  and  one  1-bit 

*  variable  out  to  calling  program. 

* 

*  Tom  Guthrie  24  Jan  05 

* 

*  This  function  calls  a  macro.  The  macro  samples  33  data  lines  and 

*  returns  the  values  to  this  function. 

* 

*  This  function  then  splits  out  the  32  bit  input  into  four  OBM  banks 

*  where : 

*  Bank  A  =  I  primary  channel  information  =  bits  7:0 

*  Bank  B  =  I  secondary  channel  information  =  bits  15  :  8 

*  Bank  C  =  Q  primary  channel  information  =  bits  23:16 

*  Bank  D  =  Q  secondary  channel  information  =  bits  31:24 

*  Bank  E  =  PRF  information  from  a  separate  variable 

* 

*  When  filled  to  MAX_OBM_SIZE ,  the  OBM  banks  are  passed  back  to  the 

*  calling  function. 

**********************************************************************/ 

#include<libmap . h>  //  New  lib  to  facilitate  map  calls 

void  strbitin  (long  long  A[],  long  long  B[],  long  long  C[], 
long  long  D[],  long  long  E[],  int  mapnnm)  { 

int  out,  out 2,  i,  temp/  //  storage  var,  stor  var,  counter,  temp  var 

0 BM_B ANK_A  (AL,  int64_t,  MAX_OBM_SIZE )  //  I  primary 

OBM_BANK_B  (BL,  int64_t,  MAX_OBM_SIZE)  //  I  secondary 

OBM_BANK_C  (CL,  int64_t,  MAX_OBM_SIZE)  //  Q  primary 

OBM_BANK_D  (DL,  int64_t,  MAX_OBM_SIZE)  //  Q  secondary 

OBM_BANK_E  (EL,  int64_t,  MAX_OBM_SIZE)  //  PRF 
out  =  55/  //  Initilize  out 

for  ( i= 0 / i <MAX_OBM_S I ZE / i ++ )  { 

bitin (& out,  &out2)/  //  Get  data  from  pin(s) 

/ /  Variable  Out  packed  with  four  variables . 

AL[i]  =  out  &  0x00000000000000ff/ 

BL[i]  =  (out  &  0x00 000 00 000 00 f f 0 0 )  »  8/ 

CL [ i]  =  (out  &  OxOOOOOOOOOOffOOOO)  »  16/ 

DL [i]  =  (out  &  OxOOOOOOOOffOOOOOO)  »  24/ 

EL [ i]  =  out 2 / 

}  //  End  for  (i=0/i<MAX  .  .  . 

temp  =  MAX_OBM_SIZE*sizeof (int 64_t ) /  //  Here  to  facilitate  DMA->CM. 

//  is  the  length  of  the  entire 
/ /  array . 

//  Transfer  the  I  primary  channel  data  array  back  to  calling  program 
DMA_CPU  (OBM2CM,  AL,  MAP_OBM_s tripe ( 1 , "A" ) ,  A,  1,  temp,  0)/ 
wait_DMA  ( 0 ) / 

//  Transfer  the  I  secondary  channel  data  array  back  to  calling  program. 
DMA_CPU  (OBM2CM,  BL,  MAP_OBM_st ripe ( 1 , "B " ) ,  B,  1,  temp,  0)/ 
wait_DMA  (0)/ 

//  Transfer  the  Q  primary  channel  data  array  back  to  calling  program. 
DMA_CPU  (OBM2CM,  CL,  MAP_OBM_st ripe ( 1 , " C " ) ,  C,  1,  temp,  0)/ 
wait_DMA  (0)/ 

//  Transfer  the  Q  secondary  channel  data  array  back  to  calling  program. 


DMA_CPU  (OBM2CM, 
wait  DMA  ( 0 ) / 

DL, 

MAP_OBM_s tripe (1, ' 

'D") 

/  D, 

1, 

temp. 

0)  / 

//  Transfer  the 

PRF 

data  array  back  to 

calling 

program . 

DMA_CPU  (OBM2CM, 
wait  DMA  ( 0 ) / 

}  / /  End  strbinin 

EL, 

MAP_OBM_s tripe (1,  ' 

’E") 

/  E, 

1, 

temp. 

0)  / 

Unpacking  here . 
//  I  prim 
//  I  sec 
//  Q  prim 
//  Q  sec 
//  PRF 
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MATLAB  CODE  USED  TO  TEST  SAMPLED  DATA 


%  Thesis  Test  Data 
%  Tom  Guthrie 
% 

%  Date:  24  Feb  05 
clear;  close  all; 

%  Get  data  from  input  file  for  processing  and  graphing 
%  The  input  file  name  varies  depending  on  the  sample 
%  taken. 

BlkSz  =  700; 
numBlk  =  47; 

%  w  &  x  used  to  select  a  range  of  samples . 
w  =  198992;  %  Start  range 

x  =  w  +  BlkSz*numBlk;  %  End  range 

%  523776  =  MAX_OBM_S I ZE 

load  -ASCII  oR4Febkf.txt  %  File  to  be  loaded 

i  =  oR4Febkf ( w : x, 1 ) ;  %  Sample  number 
Ipri  =  oR4Febkf (w : x, 2 ) ;  %  I  primary  channel  voltage 
%Isec  =  oR4Febkf ( w : x, 3 ) ;  %  Not  used  in  this  example 

%Qpri  =  oR4Febkf (w : x,  4 )  ; 

%Qsec  =  oR4Febkf (w : x,  5 )  ; 

PRF  =  100  *  oR4Febkf (w: x, 6) ;  %  PRF  signal 

%  Scaled  for  plot 
%  visibility . 

%  Summing  the  raw  data  values  of  the  radar  system. 

%  This  loop  sums  every  BlkSz  samples  then  stores  it 
%  in  a  one  dimensional  array.  The  I  primary 
%  voltage  level  and  the  PRF  are  targets  for  the 
%  the  summation  process . 

%  The  outer  loop  (q)  divides  the  number  of  samples 
%  samples  (i)  into  blocks  which  are  BlkSz  long 
%  samples  long.  The  inner  loop  sums  the  BlkSz 
%  values  which  are  stored  in  suml  and  sumPRF . 

%  sumPRF  is  scaled  previously  by  a  constant  to  make  it 
%  highly  visible  in  subsequent  plots .  Notice  the 
%  summation  is  of  the  absolute  voltage  value  of 
%  the  I  primary  voltage.  In  this  coding  example, 

%  i  =  sample  number,  I  =  Ipri  =  voltage  level  of 
%  of  the  I  channel. 

temp  =0;  %  Temporary  storage  variables 

temp 2  =  0; 

for  q  =  1: numBlk 

for  r  =  1 : BlkSz 

temp  =  temp  +  abs  ( Ipri ( (q-1 ) *BlkSz+r)  )  ; 
temp2  =  temp2  +  abs (PRF  ( (q-1) *BlkSz+r)  )  ; 

end 

suml (q)  =  temp; 

sumPRF (q)  =  temp2; 

temp  =0;  %  Reset  the  temp  variables 

t  emp  2  =  0 ; 

end 

kmpBlk  =  BlkSz  *  1.5/1000; 
mpBlk  =  kmpBlk  *  0.6215; 
nmpBlk  =  kmpBlk  *  0.540541; 

Rkm  =  linspace(l,  kmpBlk  *  numBlk,  numBlk);  %  Range  km 
Rm  =  linspace(l,  mpBlk  *  numBlk,  numBlk);  %  Range  miles 
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Rnm  =  linspace(l,  nmpBlk  *  numBlk,  numBlk);  %  Range  naut .  miles 
figure ; 

plot (Rkm,  suml,  Rkm,  sumPRF,  ' r* ' ) ; 

axis  tight; 

xlabel ( 'Range  (km) ' ) ; 

ylabel (' Processed  Radar  Return'); 

title  ('AN/SPS-65  Radar  Return  via  SRC-6E  processor'); 
legend (' \Sigma  I  Channel  Signal \Sigma  PRF',2); 
grid  on; 

figure 

plot (Rnm,  suml,  Rnm,  sumPRF,  ’ r* ' ) ; 
axis  tight; 

xlabel (' Range  (nautical  miles)'); 
ylabel (’ Processed  Radar  Return'); 

title  (’AN/SPS-65  Radar  Return  via  SRC-6E  processor'); 
legend (’ \Sigma  I  Channel  Signal ’,' \Sigma  PRF',2); 
grid  on; 

figure 

plot (Rm,  suml,  Rm,  sumPRF,  ’ r* ’ ) ; 
axis  tight; 

xlabel ( ' Range  (miles )  ' )  ; 

ylabel (' Processed  Radar  Return'); 

title  ('AN/SPS-65  Radar  Return  via  SRC-6E  processor'); 
legend (' \Sigma  I  Channel  Signal ',' \Sigma  PRF',2); 
grid  on; 
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